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Welcome |! 


¢Final design review of Astrobee 

¢ Delta Periodic technical review #3 (PTR 3) 
¢Logistics 

*Emergency exits 

¢Rest rooms, lunch, demo 


°(A few) introductions 
¢GCD / HET2 / Astrobee key people 
¢ HEOMD/SPHERES (Crusan, Martinez, Benavides) 


¢PTR board (Fong, Provencher, Smith, Barlow, 
Smith, Crusan, Benavides) 


Periodic Technical Review 
(HET2 Project Plan) 


¢ Periodic Technical Review (PTR) 


¢ Monitor and communicate technical and programmatic 
progress against the approved baseline 


¢ Review plans for upcoming work 


¢The PTR board consists of (or an assigned delegate): 
° HET2 PM: Terry Fong 


e Astrobee management: Chris Provencher, Trey Smith, 
Jonathan Barlow, Ernie Smith 


¢ AES Director/SPHERES PM: Jason Crusan, Jose Benavides 


e All stakeholders who contribute or are interested in 
the project are invited to participate 


Delta PTR 3 


¢ Demonstrate that the design has sufficiently matured and has an acceptable 
level of risk 
¢ Hardware expected to be more mature (with known design gaps) 
¢ Software maturity expected to follow, with planned design beyond PTR 3 
¢ Examine the results of Prototype testing (and any impact on the Certification 
Unit). 
° Today’s objectives : 
¢ Focus on new/changed design since PTR 3 (June 2016) 
¢ Ensure a thorough review of the products identified for PTR 3 
¢ Ensure Prototype 4D activities to date do not adversely impact forward plans 
e Ensure issues raised during the review are appropriately documented and a plan for 
resolution is prepared 
¢ Following A\PTR 3, Astrobee will: 
¢ Complete design for flight (any open items) 
¢ Complete Prototype 4D testing 
¢ Proceed with Certification Unit procurements 


PTR 3 Entrance Criteria 


v The element has successfully completed the previous planned milestone reviews, 
and responses have been made to all issues and actions, or a timely closure plan 
exists for those remaining open. 


v The PTR 3 agenda, success criteria, and instructions to the review board have 
been agreed to by the technical team, element lead, and review chair prior to the 
review. 


v The PTR 3 data package (IRG-FFRP-003) with the following products are available 

to the participants: 
IRG-FFO17 Astrobee Design Document with a design overview (to subsystem level) that 
can be shown to meet requirements and key technical performance measures 
Astrobee document tree 
Technical resource margins 

v Updated PTR 3 technical products 
Updated schedule, cost, and risks 


PTR Board + Reviewers 


¢We want your feedback ! 
¢ Identify what we are doing well + what we can do better 
¢ Identify new issues or concerns 
¢ Suggest improvements 
* Recommend how and when Astrobee should move into 
the next lifecycle phase 
¢Please keep in mind... 
¢ Astrobee is an element within the HET2 project 
¢ PTR objectives 
e Astrobee is 7120.8 (Research & Technology) with ISS certs 
¢ Astrobee is not a spaceflight project 


Overview 


¢ Develop, test, deliver 2 free 
flying robots for ISS IVA use 


¢ Ayear project (FY15-FY17) 
under Human Exploration 
Telerobotics 2 (HET2) 


¢ Sponsor: Space Technology 
Mission Directorate, Game 
Changing Development 
Program 


¢ Technology infusion to ISS 
payloads & operations 


Astrobee Organization 


HET-2 Project 
Terry Fong (ARC) 
Maria Bualat (ARC) 


Astrobee Element 
Chris Provencher (ARC) 


SMA Robotics 
Ernie Smith (ARC) Engineering 
Trey Smith (ARC) 
Teams 
Mechanical, Avionics, Integration & Test 
Comm, FSW, GN&C, Prop, Jonathan Barlow (ARC) 
Thermal, GDS ARC 


ARC/JPL 


Systems Engineering Team 


¢ Trey Smith (ARC-TI, Lead) 

¢ Jonathan Barlow (ARC-T]1) 

¢ Maria Bualat (ARC-T]) 

¢ Estrellina Pacis (ARC-T1) 

¢ Hugo Sanchez (ARC-RE) 

¢ Allison Zuniga (ARC-TI, alumna) 


I&T Team 


¢ Jonathan Barlow (ARC-TI, Lead) 

¢ Max Feinberg (Univ. of Illinois, OSSI intern) 
¢ John Love (ARC-RD) 

¢ Corey Snyder (ARC-SCF) 

¢ Olivia Formoso (ARC-RE, alumna) 


Avionics Team 
C&DH, EPS, Dock, Perching Arm, Propulsion 


© Vinh To (ARC-TI, Lead) 


¢ Dmitriy Arbitman (Univ. of California San Diego, intern, alumnus) 
¢ Steve Battazzo (ARC-RE) 

¢ Jon Dewald (ARC-RE, alumnus) 

¢ Brandon Gigous (Univ. of Illinois, OSSI intern, alumnus) 

¢ Jason Lum (ARC-TI, alumnus) 

¢ Nghia Mai (ARC-RE) 

¢ In Won Park (ARC-TI) 

¢ Cedric Priscal (ARC-T1) 

¢ Jongwoon Yoo (ARC-TI) 

¢ Shang Wu (ARC-RE) 


Communications Team 


Free Flyer Comm, E2E comm standards 


¢ Ted Morse (ARC-TI, Lead) 
¢ Vinh To (ARC-TI) 


¢ Jason Lum (ARC-TI, alumnus) 


Flight Software Team 


Flight software, GNC software 
¢ Lorenzo Fluckiger (ARC-TI, Lead) 


¢ Oleg Alexandrov (alumnus) 

¢ Katie Browne (ARC-TI) 

¢ Brian Coltin (ARC-T1) 

¢ Phil Cooksey (Carnegie Mellon Univ., OSSI intern) 

¢ Ravi Gogna (ARC-TI, alumnus) 

¢ Dong-Hyun Lee (ARC-T]I) 

¢ Zack Moratto (ARC-TI, alumnus) 

¢ Ted Morse (ARC-T1) 

¢ Andrew Symington (ARC-T1) 

¢ Mike Watterson (Univ. of Pennsylvania, NSTRF intern) 


Ground Data Systems Team 


¢ DW Wheeler (ARC-TI, Lead) 

¢ Maria Bualat (ARC-TI) 

¢ Ryan Goetz (JPL-397J) 

¢ Connor Hitt (Univ. of Texas, intern, alumnus) 

e Jessica Marquez (ARC-TH, collaborator) 

¢ Andy Martinez (ARC-TI, Education Associates intern, alumnus) 


¢ Jay Torres (JPL-397G, alumnus) 


GN&C Team 


GNC software, Prop software 


e Jesse Fusco (ARC-RE, Lead) 
¢ Michael McIntyre (ARC-RE, alumnus) 
¢ Robert Nakamura (ARC-RE) 


Mechanical Team 


Structure, Propulsion, Dock, Perching Arm 


¢ Hugo Sanchez (ARC-RE, Lead) 

¢ Jeff Blair (ARC-RE) 

¢ Earl Daley (ARC-RE) 

¢ Brian Koss (ARC-RE, alumnus) 

e Alex Langford (ARC-RE, alumna) 

¢ Alberto Makino (ARC-RE) 

¢ Travis Mendoza (Univ. of Southern California, intern, alumnus) 
¢ Mike McIntyre (ARC-RE) 

¢ Blair McLachlan (ARC-AOX) 

¢ In Won Park (ARC-TI) 

¢ Troy Shilt (Ohio State Univ., OSSI intern) 

¢ Rafael “Omar” Talavera (ARC-RE) 

¢ Watson Attai (ARC-RE) 7 


Thermal Team 
Free Flyer, Dock 


¢ Jeffrey Feller (ARC-RE, Lead, alum) 
¢ John Love (ARC-RD, Lead) 

¢ Earl Daley (ARC-RE) 

¢ Ali Kashani (ARC-RE) 

¢ Blair Mclachlan (ARC-AOX) 

¢ Vinh To (ARC-TI) 


Human-Robot Interaction Team 


Free Flyer, Control Station 


¢ Yunkyung Kim (ARC-TI, Lead) 

¢ Liz Cha (Univ. of Southern California, NSTRF intern) 
¢ Terry Fong (ARC-T]1) 

¢ Hyunjung Kim (ARC-TI, alumna) 

¢ Pem Lasota (MIT, NSTRF intern) 

¢ Youngwoo Park (ARC-TI, alumnus) 


¢ Dan Szafir (U-Wisc, NSTRF intern, alumnus) 


Og Robotics Research Facility 
—_ Sale 


AES, SPHERES Program, Researchers 


Mobile Camera Tasks 


ISS Program, FOD, POIC 


ISS Program, FOD, POIC 


Dock & Resupply 


Self diagnostics 


Agenda 


[tm | oxmten| nee | ae 
—220_| tenons | wetanetns 


pi tn —$ 
Pe | 
psoas | its | teamteads | oesign 

200 | 04s ftunch 
| szas | os0 | | temo 
| asas | its | teamtesds | oesign 
| seso | ons | | reak 
| seas | 030 | ey | systems engineering 
| 1sas_ | 030 | Jonathan | integration atest 

isas_| 030 | emi fsatey 
| 16as_| oas | chris | roject Management 
| 1630 | 01s | maria | operations 
| seas | ots | emis | conctusion 


Testbed Capabilities 


Multiple free flyer operations 

Mobile sensing & manipulation tasks 

Holonomic motion 

Remote control 

Host payloads with physical and software interface 


Not reverse compatible with existing SPHERES payloads 
(without an adaptor) 


Holonomic control 
Navigate USOS 
Multiple peripheral ports 


Reconfigure parameters per 
payload 


Open API for payloads 

Position: +/- 20 cm, +/- 2.cm 
Angle: +/- 20 deg, +/- 8 deg 

Max acceleration: 10 cm/sec? 

Max velocity: 50 cm/sec 

Avoid hitting unexpected obstacles 
Avoid keep out zones 


Validate path against map 


Free Flyer Key Requirements 


Monitor battery charge 
Noise requirements 
Tolerate collisions 

Size: 12” x 12” x 12” 

Mass: 8 kg 

Stream and record HD video 
Sortie durations & energy storage 
Perch on handrails 
Autonomous docking 
Replaceable modules 
Upgradeable software 


ISS ICD & Safety 


Presented and baselined at PTR1 


Ground Control 
Manual Control 
Plan authoring 


Plan control (select, upload, run, 
pause, abort, skip) 


Provide Pls access to science data 
Software install (guest science) 
Monitor multiple robots 

Identify free flyer being controlled 
Remote Terminate 


Real-time telemetry display 


Ground Data Systems 
Key Requirements 


2D and/or 3D telemetry 
visualization 


Simulation for plan visualization 


Contro 


| station health & status 


Provide data storage 


Minimal UI training for Crew and 
Operatory Stations 


Upgradable hardware/software 


ISS ICD 


Presented and baselined at PTR1 


Dock Key Requirements 


¢ Free flyer and dock must be able to complete all 
physical connections without crew assistance 


° AR target to assist free flyer localization during dock 
approach 


«Recharge spare batteries 

* Provide free flyer with high bandwidth wired 
connection to ISS LAN 

*Dock provides two free flyer berths 

°ISS ICD & Safety 


Presented and baselined at PTR1 


System Design Overview 


Delta Periodic Technical Review 3 
February 1, 2017 


Astrobee Elements 


Astrobee 


Free Flyer 


his | 


ISS (USOS) 
Crew Control Station 


MSFC POIC 


White Sands 


Free Flyer 


Subsystems 


Flight 
Software 
UTaarice, 
( oat rae retraces 4 


Propulsion 
Command & 
Data Handling 
Electrical 
Power System 


External | 
1 Sensors J 


| 
Comm 


} Mechanism 


Mechanism 


Avionics 


( 4 
Dock Adapter L 
dl 


Ground Data 
System 
Control 
Station 
Ground Data 
Storage 
ISS Data 
Storage 


Engineering 
Tools 


rc r— 
| | : 


12.5 x 12.5 x 12.5 inches 
8 kg mass target 


FORWARD 


FORWARD 


12.5 x 12.5 x 12.5 inches 
8 kg mass target 


¢ Current best estimate of flight 
mass is 8.7 kg, above TPM 


threshold 
¢ Will discuss this in detail later 


Project Response to PTR3 Feedback 


¢Many design gaps and risks were identified at 
PTR3 


eWe ped the risk was too high to immediately 
— from Prototype 4C (“P4C”) to cert unit 


vaacelom do one more round of prototype 
testing prior to cert unit 
¢ Integrated P4D — Incorporates many of the post-PTR3 
design changes 
¢ Stand-alone prototyping of some components — Used 
to save resources when we could retire the risk 
without integrated testing 


Robot Prototype Versions 


PTR3, June 2016 Delta PTR3, Now 


i il v6 

| v5 i [Partial build] 

[Retrofit v4] Hard shell 

v4 ll Nozzle servos l Many updates 


Propulsion Module 


v7 

: [Retrofit v6] 
Add retention 
levers 


v6 

v5 Ultem structure 

Joint servos Gripper improvements 
Avionics Wire/tendon routing 


Perching Arm 


Robot + Central 
Module 


P4C P4D 
Metal frame # 
Many updates 


v6 


v5 [Partial build] 
[Retrofit v4] Hard shell 
v4 Nozzle servos Many updates 


Perching Arm 


v6 

v5 Ultem structure 

Joint servos Gripper improvements 

v4 Avionics Wire/tendon routing 


v7 

[Retrofit v6] 
Add retention 
levers 


Robot / Central Module Versions 


Robot + Central 
Module 


Metal frame 
Many updates 


¢External appearance 
design 

eSignal light design 

¢Human factors 


throughout (e.g. 
restraining straps) 


Structure 


¢Camera placement, 
servicing, lens protection 


¢Payload interface 


¢Wire routing and thermal 
air flow 


«Plenum lid / hard shell 
¢Corner bumpers 
eSoft layer and skin 


AVIONICS 


¢Safety improvements 
(over-current, over- 
temperature controls) 


¢|mproved support for 
software/firmware 
updates 


«SpeedCam 


Comm 


eAntenna placement 


¢Video distribution 
approach 
faa: \e ¢Telemetry recording 
-—e@  — and downlink 
management 


Flight Software 


¢eMode management 
and sequencing 


¢Onboard trajectory 
generation and 
collision detection 


Obstacle 


Fault management 
infrastructure 


°Visual odometry 


°6 DOF gantry testing 
in 1g 


Fault management 


Ground effect test setup 


Moan+3sigma value = 


Monte Carlo error distribution 


Perching Arm 


«Joint servo motor 


«Wire and tendon 
routing 

¢On-orbit gripper 
swap/upgrade 


DOCK AIR 


Thermal Baffle TAKE 


DOCK AIR 
EXHAUST 
WITH 
DEFLECTOR 


DOCK AIR EXHAUST IF 
DEFLECTOR IS REMOVED 


Thermal 


¢Thermal testing and 
safety analysis for 
peripheral heat 
sources (e.g. arm 
motors) 


eArm gripper motor 


¢Dock thermal intake 
screen / minimize 
crew cleaning 


¢Flexible ISS placement / 
attachment approach 


¢New remote wake 
function (requires 
“smart dock”) 


«Separated COTS battery 
chargers from docking 
Station to reduce 
volume / ease 
placement concerns 


Dock Processor (same as LLP) 


Ground Data System 


~ S| *Guest science 
interface 


¢Config file 
management 
Fault management 


Astrobee 
Human-Robot Interaction (HRI) 


Design Overview 


Design Goal 


| Characteristics _ Attractiveness 


G@ gd ==. 


Sleek, not bulky Engagement by identification Affective & intuitive signals 


mUlaved(elat-]M-Viielact-lala= 


a are. 


Clear indication of orientation One-hand usability Adjustable Velcro length 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Maturity / Risk | Forward Work 


Signal LEDs High / Low - 
Light signaling pattern Med / Low Follow up with crew office 
Sound signal Low / Low Design sound & follow up with crew 


office 


Touch screen Low / Low Not started yet 


New/Changes from PTR3 


Signal LEDs - New signal LED arrays on each prop module 
Light signaling pattern - Newsignaling LED patterns for each robot state 
Sound signal - Define useful situation 


Touch screen - Define useful situation as signal modality 


Purpose of HRI 


Human Perspective 
¢ Proximal user (Crew): Aware robot states 
without annoyance and task disruption 
¢ Distant user (Ground Operator) : No latency for 


signaling states 


Human ¢ Represent various state having different Astrobee 


criticality, urgency, and amount of information 


Robot Perspective 


Non-verbal Signal 


¢Representing information that is important but not critical 
¢Provide subtle changes to reflect updates without distraction 


¢Moving from the periphery to the focus of attention 


Light Sound 
e Visually perceived before ¢ Convey information 
Strength consciously attention without visibility restriction 


¢ Sophisticatedly express states ¢ Strong focus of attention 


¢ Requires line of sight ¢ Can be perceived as 
Weakness e Interference from natural interference or annoyance 
and artificial sources ¢ Masked by other sound 


Sound 


Movement 


Light 


Touch Screen 


Touch (Haptic) 


Interaction Modality 


Physical Distance 


Separate (invisible) Distant Close 


Alerting + 


Alerting a state 
voice command 


Motion Orientation, Gesture 


Conveying intent 


Conveying 


SOnVeViMeiite at intent / information 


Receiving 
crew’s input 


Signal Light Concept 


| HOLWH 


Lix3 
a"! : 
- 


Notification Level & Robot States 


Ignore _ Change Blind §=Make Aware Interrupt =| Demand Action | 


Need help state ¢—>- CRO a WOR 
(Blocked robot view / Low battery / Stuck by obstacles) 


Moving state 


Instant state Eg; : Alert state ~ 
(Changing direction) | (Running into crew) 


Less active state 


(Stationary as Perched / Hibernated /Docke) 


Proressive.s| state 


(Battery charging / Data transmitting / Task executing) 


@— Start state <— Transfer state @— Endstate 


Signal Light Design 


Stationary 


Blink, White Blink, Green Flowing, Green 


Data Transmit / Task Execute Stuck by Obstacle Running into Crew 


Spinning, Cyan Blink, Amber 


Crew Privacy 


e Using blue color only for indicating Audio Recording state 


¢ Representing Audio Recording states on all side of Astrobee 
- status LEDs on front/aft face & signal LEDs on both props 


Front face Prop Audio Recording 
while Moving 


Astrobee Structure Subsystem 


Design Overview 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 


Maturity / Risk | Forward Work 


Core Module High / Low - Implement P4D findings 
- Finalize battery retention system 


Top Forward Module High / Low - Implement P4D findings 
- Incorporate Al. Structure 
- Incorporate NavCam protection 


Forward Group High / Low - Implement P4D findings 
Aft Group High / Low - Implement P4D findings 


Forward and Aft Bezels Medium / Low’ - Implement P4D findings 
- Finalize inlet screen 


New/Changes from PTR3 


Core Module - Changed replaceable modules and incorporate designs 
- Changed fwd antenna locations 
- New camera locations 
- New button location and design 
- New status led designs 
- Changed Avionics location 
- New Payload attachment design 
- New top cover removal screw 
- New wire routing features 


Top Forward - Changed replaceable modules and incorporated designs 
Module - New camera locations 
- New wire cover design 


Forward Group - Changed touchscreen location 


Aft Group - Changed docking cups orientation and cup size 
- Changed aft antenna location 


Forward and Aft - Change fwd and aft cooling air vents 
Bezels - New forward bezel configuration 


Astrobee Images 


Central Core 


Forward Top Aft Top 
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Battery 


(1 on top + | aa 4/7) LED 
i al Indicators 


1 on bottom) 


SpeedCam 
Terminate Button 


Microphone / Speaker 
Laser 


SciCam 
HavCam 


NavCam 


Touch Screen / 
Touch Screen Activate Button 


Status LEDs 
Power Switch 
Fwd LED Light 
Wake Button 


Battery 


PerchCam 
DockCam 
Status LEDs 


Aft LED Light 
Dock Adapter 
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Payload Layout 


2X Clevis 


Core Connector 
31 POS PLUG (M835130E03C) 


Perch Arm is larger 
than 1U 


4X #8-32 Thread 
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Payload Mechanical Attachment 
Options 


4X Fastener Payload Attachment 


uick “No Tool” Payload Attachment 


2X Lever 
(open position) 


4X Captive 
Fasteners 


Lever engages and 
disengages 
payload connector 
and provides 


mechanical 
attachment 
Lever in “Locked” Al 
a S 
position <= 


~~ 


“Lock” 
Position 


“Un-Lock” 
Position 
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Core and Forward Module 


Top Forward Module Battery Retainer 
(in ABS Prototype) 


Forward Bezel Fwd Antennas _ Air deflector 
Not shown 


Aft Module 


Perch Cam 


DockCam 
Aft Antennas 


Aft LED Light 
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Astrobee Propulsion Subsystem 


Design Overview 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 


Maturity / Risk | Forward Work 


Plenum High/Low 
Top Cover and Skins High/Low 
Signal Lights High/Low 
Restraint Straps High/Low 
Impact Mitigation High/Low 
Nozzles High / Low 


Impeller/Motor High/Low 


Improve strength 


Finalize skin attachment methods. 
See Yun’s slides 


See Yun’s slides 


Finalize bumper nomex cover design 


New/Changes from PTR3 


Plenum - Added features for covers and nozzle changes 
Top Cover and - NewdAl. Top Cover with softlayer 

Skins - New skin design 

Signal Lights - New signal light design 

Restraint Straps - Newrestraint strap design 

Impact - Finalized bumper materials 

Mitigation - Confirm bumper force performance with testing 


- New softlayer design 


Nozzles - New vibration isolation and seal components 
- Change to servo spline drive shaft 
- Change drive shaft gear 
- New servo thermal sensor 


Impeller/Motor - Newstiffened impeller 


Astrobee Design 


Two identical Propulsion Modules on Astrobee 


Left Propulsion Module Right Propulsion Module 
Z Front ISO View Aft ISO View 


Top Cover and Skins 


Plenum 


Top Cover w/ softlayer 


ee il 


Skin Sample made in JSC Soft Goods 


Skin 


Top Cover: Aluminum sheet with soft layer and Velcro patches 
Skin Material: Nomex / Chemglass w/ Velcro Hook and Loop patches 
Graphics: Printed on Nomex 
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Programmable Signal Lights 


Seven LEDs wrap around front and aft edges 


Fifteen (each) LEDs on ~6” dia. 


LED: %” Square Multi-color Adafruit NeoPixel 


Restraint Straps 


Strap with Velcro hook allows Astrobee to be restrained to ISS loop patches 


Two deployable straps 
for restraining Astrobee on 
station. Velcro Hook on ends of 
straps 


Strap is unfolded Strap is unfolded Fully Deployed 
1 fold 2 folds ~ 10” Strap 


Strap Material: Nomex with Velcro Hook and Loop patches 
Full Length: ~10 inches 
Design Strength: 10 Ibf 80 


Impact Bumpers & Surfaces 


“Soft Layers” 1/16” thick foam 


Soft Layers Defined (Layer A and Layer B) 


Skin 
(backer w/ NOMEX) 


( M407) Soft layer A 
(Peel Ply / T T/ Bisco) 


Hard Cover (Al.) 


1/16” thick HT-800 Bisco 
002” thick 3M 91022 Transfer Tape 
w/PET peel ply (not shown) 


Prop Covering X-Sec 


Soft layer B 
(Peel Ply /TT/ Bisco / T T / Nomex) 


All other Covering X-Sec 


x 


8X Corner Bumpers f #)— NOMEX (TBD) 


_— =e ! | = ain sani 
| +; 002” thick 3M 91022 Transfer Tape 


= “/PET peel ply (not shown) 


Covers 
81 


Impact Bumpers 


Max operational resultant force < 125 Ibf, Max force < 1000 Ibf 


2X Captive 
Screws hold 
bumpers on 


Run 34 (M @ 6 Bag, V = 0.758 


Force (6) 


Bumper Material: 29) 0 02 
Arti-lage SH28 PU 
energy absorbing 


Impact Bumper Testing 82 


Nozzle Subassembly 


Drive Gear 


Idler Gear 
Flapper Gear / Shaft 


Nozzle Isolation Testing ~ fa 


Flapper Gear / Shaft 


¢ Vibration Isolation (Sorbothane) 


* Reduced Drive Gear from .75 to .50 Dia. Wl Sec B-B 
¢ COTS MKS Servos w/ thermal sensor A 
¢ Splined drive shaft (Cert/Flight) Spline Coupling 


Vibration Isolators 


Sec A-A 
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Astrobee Propulsion Subsystem 
Avionics and Software 


Delta-PTR3 Design Overview 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 


however there are some known design gaps described below. 
All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Maturity / Risk | Forward Work 


Board layout updates required 
before Cert build 


Prop Avionics Hardware High/Low 


PMC SW High/Low 


Summary of Changes from PTR3 


New / Changes 


Nozzle Servos 


PMC Board 


PMC Board 


Temp Sensors 


Replaced MKS DS92 with DS95 


Added PWM chip for nozzle servo control 
Added LED processor (Independent circuit from prop control) 


Temperature sensors (AD590) added to all servos and impeller 
motor 


Propulsion 
Electronic Components 


Motor Controller 
Maxon ESCON Module 24/2 


PMC Pressure Transducer 
Microcontroller Honeywell HSCDRRNO1OMD2A3 
Microchip 


PIC32MX795F512H 


. nes ie 

gee ee reer er 

me Wa CaCO 
? 


x eeeeeeeeeee 


Astrobee > 
PMC Controller Board 

},Oraang # FFOWOO3IS 
Rev | ‘@) 
January 2016 


Impeller Motor 
Maxon EC45 Flat, 30W 


Servo connectors 


Connection to Align DS416M 


LLP/EPS boards 


PMC Architecture Diagram 


NEW 
es 5 
LED = | 


Microcontroller LED array 
(PIC32MX210F016B) 


LED +5V 


6V Regulator 


Current Sense 


Servo Current 


3.3V Regulator 


PWM 
Driver 


Servo PWN Position Cmd (x6) 


Temperature Servos 
Sensors (7) 


Pressure Sensor (I2C) | 


Temperature Sensing 


PMC 
Microcontroller 
(PIC32MX795F512H) 


Pres Sensor 
Motor Windings 


Bus Voltage 
(9.8V-16.8V) 


Speed Cmd (PWM ) 


Motor Enable 
Impeller Motor 


Speed Sense Controller 


I2C Bus 
(Maxon ESCON) Hall Sensors 


Current Sense 


Impeller 
=—_ POwer Motor 
Central es 
Module =—— Digital 
(LLP) — PWM 
=—— |2C 


Propulsion 
Software: PMC Functions 


PMC Board Functions 


Control impeller motor speed 

Control nozzle servo motor positions 

Mode management 

Receive and execute commands from the LLP 
Return telemetry to LLP 

Read plenum pressure sensor 

Read motor speed from motor controller 
Read motor current from motor controller 
(New) Read temps from 6 servos + impeller motor 
10. Perform propulsion FM activities 

11. (New) Control LED signal array 


Oe a eS 


Propulsion 
Software 


¢Development environment 
° MPLAB X (v3.45) 
¢XC32 Compiler (v1.42) 
¢ Harmony Configurator (v1.09) 


*Programming 


¢PMC/LED SW upload capability from ground 
¢ Updated via 12C Comm path 


¢ Directly to the PMC board via a mini-USB port 
¢ Motor controller firmware not to be updated on 
orbit 


Newtons 


0.700 


0.600 


0.500 


0.400 


0.300 


0.200 


0.100 


0.000 


Performance 


0.849 


Astrobee Max Forces (2 PMs) - CBE 


Y 


m2000RPM #8 2500RPM wm 2800 RPM 


Astrobee CDH, EPS, & Sensors 
Subsystem 


Design Overview 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 


Maturity / Risk | Forward Work 


Backplane board High / Low 
Data bus High / Low 
Low level processor High / Low 


Mid/High level processor High/Low 


Touchscreen High / Med 
Flashlights High / Low 
Payload connector High / Low 


Buttons/switches/LEDs High / Low 
EPS High / Low 
SpeedCam Med / Low 


HW payload over current 


USB OTG support 
Speaker+Mic, USB OTG support 


Ribbon cable routing 


HW over current, HW over temp 


More testing 


New/Changes from PTR3 


EPS - HW current limit for payload power 
- HW over temperature protection 
- Improved battery charging 


Backplane - HW current limit for payload power 


MLP/HLP - Speaker and Microphone fix 
- Added Fastboot support 
- SMA connector for WiFi antenna 
- Additional mounting holes for heat sink 


LLP - GPIO line to MLP & HLP volume for Fastboot 
SpeedCam - Big redesign 


Avionics Stack 


Avionics Stack 


EPS Diagram 
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*HW over current protection 
¢4 Payloads 


*HW over temperature protection 
°LLP 
°MLP 
°HLP 
¢ Flashlights 
¢ System 


¢Improved battery charging 
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EPS HW over temperature 
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Avionics Diagram 
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MLP+HLP Carrier 


°Fix soeaker and mic issues 

¢Added Fastboot support for MLP and HLP 
¢Changed Wifi antenna connector 

¢Added more mounting holes for heat sink 
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Payload Bay Connector 


¢31 pin D-sub connector 
Vi att, GND 

°USB 2.0 

¢More robust 

¢Premade harness 


eMale side on Astrobee 


Payload Bay Connector 


¢Pre-twisted pair cable for: 
_f/ p, ¢ USB data 
OY, ¢ Ethernet 


YY ¢ Power 


«Reduces wire bundle size 
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Astrobee Comms Subsystem 


Design Overview 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Maturity / Risk | Forward Work 


Antenna High / Low 
Network Configuration High / Med 
Data Transfer High / Med 
DDS Routing Service High / Med 


Video Multicasting Med / Med 


New/Changes from PTR3 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Overall Design Added Dock CPU. Add HOSC relay. 

Antenna Changed in-line connector. Changed location of antennas. 
Telemetry/Video Added data relay through the HOSC. 

Engineering Tools Updated diagram. 


S/W Updates Use Dock CPU instead of NAS for updates. 
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Ethernet/LAN 


Ethernet: 
Internal IP 


Ethernet: 
Internal and 
Payload LAN 


WiFi: 
Payload LAN 


USB 


Other/LAN 


Ground Data Relay 


¢For conserving bandwidth, only one stream of 
data & video will flow to the ground per robot. 
Data is relayed to multiple ground stations via a 
“relay” at MSFC HOSC. 


¢A computer at the HOSC routes DDS and 
steaming video traffic from ISS KUIP to 
interested ground nodes. 
¢ It will use COTS software, with custom configuration 
files. The configuration files will be under version 
control at Ames. 


¢ The DDS data relay has been tested at Ames. 


Data Paths Overview 


eAll data paths to the ground make use of KU- 
IP Services and TReK. 
¢TRek HPEG: Allows us to control our payload 
outside of the HOSC via “proxy” IP addresses. 


¢TRek CFDP: File delivery protocol based on 
CCSDS. 


Data Path: Telemetry & Video 


Crew 


Commands and Telemetry (DDS [UDP/IP]) ol aage) 
Station 


Science Cam HD video (RTSP [UDP/IP]) 


Commands and Telemetry (DDS [UDP/IP]) 


KUIP 
Science Cam HD video (RTSP [UDP/IP]) 


(CT gelelare 


TReK-HPEG Control 
Ground Commands and Telemetry (DDS [UDP/IP]) Syecialeyal 
2 *s 


Relay 


Science Cam HD video (RTSP [UDP/IP]) 


MSFC HOSC 


Crew Control 
Station 


Legend 


Command & 
Control IP Stream 
Video 


USB 


Future Capability 


a aan 


JSC MCC 


Operator 
Control 
Station 


Screen 


Future Capability 


(Se 


MSFC POIC 
Operator 


Control 
Station 


Screen 


ARC MMOC 


Engineering 


bs Control 
Station 


Screen 


Future Capability 
PT EEN 
Non-NASA Center 


Guest 
Science CS 


Screen 


Engineering 
Workstation 


Data Flow: SW Updates, etc 


SSH/SFTP/SCP (TCP/IP) 
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WIFI Antenna 


°2.4 GHz/5.8 GHz Wifi antenna 
¢~3dBi/5dBi gain 
¢Omnidirectional 


¢Adhesive tape mounting 


¢ Additional tape will be applied to 
ensure launch survival 


ePaper thin 
Mass: 0.4/7/g 


Antenna Placement - Front 


Antennas 
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Antenna location 


Antenna Modularity 


¢ An SMA/U.FL adapter has been added to 
ease installation and replacement. 


¢ This adapter is in-line. 


Astrobee FSW Subsystem 


Design Overview 


Astrobee FSW Features 


¢ Manage Astrobee sensing and actuation 

¢ Navigate and localize within the ISS 

¢Perform autonomous docking (+ return to dock) 
¢Perform autonomous perching 

¢ Manage multisensory interaction with the crew 
eSupport “Guest Science” operations 

eSupport plan based automated tasks 

eSupport remote control from ground 

eSupport communication between Astrobees 


FSW Components and 
Design Maturity @ PTR-3 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, however there are some 
known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. Software builds are expected to 
continue through on-orbit testing. 


¢ OS (Communication Framework) 


¢ Localization 


¢ Marker less Flying ; ; 
© Docking eee High Risk Components 


* Perching have been mitigated early 
¢ Offline mapping for localization 
¢ Pose Estimation + Propulsion Control (GNC) 


/* Executive PEN 


* Mode Management 
* Sequencer (Plan Execution) Current main effort : low 


* Mobility Evolving design risk but critical components 


* Generates and validates trajectories for the overall system 
* Performs collision detection 


~° Fault Management a 
* Guest Science 

e User Interfaces Draft only 
¢ Platform Management 


Low Risk Components will be 
addressed in future Builds 


FSW Components and 
Design Maturity @ PTR-3 delta 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, however there are some 


known design gaps described below. 


All system software is less mature, and is not at CDR-level of maturity. Software builds are expected to 


continue through on-orbit testing. 


OS (Communication Framework) 


Localization 
¢ Marker less Flying 
* Docking 
¢ Perching 
Offline mapping for localization 
Pose Estimation + Propulsion Control (GNC) 


Executive 
* Mode Management 
¢ Sequencer (Plan Execution) 


Mobility Mature 
* Generates and validates trajectories 
¢ Performs collision detection 


Fault Management 


Mature 


Guest Science 


User Interfaces Mostly designed 
Platform Management 


High Risk Components 
have been mitigated early 


Low risk but critical 
Components for the overall 
system 


Low Risk Components are 
addressed in future build 


Fault management 


Fault Management Overview 


¢ Fault detection is performed by the subsystems 


e Subsystems use configurable limits to identify faults 


¢ Subsystems are be responsible for executing basic responses 
for a fault. 


¢ This allows for non-critical faults to be handled at a subsystem level 
rather than at the system level 


e Subsystems communicate faults to the System Monitor 


¢ The System Monitor can trigger system wide responses to 
faults and heartbeats 


¢~100 faults already documented in IRG-FF042-01-Astrobee- 
FMECA.xlIsx. Fault table automatically generated from the 
spreadsheet. 


¢ Reserve for “Recovery” mechanism (not implemented) 


System Manager 


¢ System Manager module is responsible for 
¢ Keeping track of which faults are enabled or triggered 


¢ Reporting subsystem warnings and triggered faults to the 
ground 


¢ Monitoring subsystem heartbeats 


¢ Responses type (can be extended): 
¢ No-op (advisory only, subsystem may provide response) 


¢ Fault (Mobility not affected, current command completes 
but system does not accept new commands) 


¢ Stop (Vehicle stops and maintain position) 
¢ Idle Propulsion (Vehicle propulsion disabled) 


Mobility 


Mobility Subsystem 
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wm Collision Detection: Problem 


¢Use depth images / point clouds to forecast 
upcoming collisions 
e Assumption: not interested in classifying or modelling 
obstacles, only detecting collisions. 


e Assumption: each measurement is discarded after 
checking, and so no map is built. 


Picoflexx Sensor | LS | 


Depth image (224 x 171 px) Point cloud 


Collision Detection: Algorithmic 
Complexity 


¢ Reduce complexity of depth data by discretizing space into K x K x K regions 
¢ Safe radius from geometric center of freeflyer given by R (size of FF + tolerance) 
° Collision checking reduces to evaluating if the squared distance between the curve 
x(t) defined by the setpoint over t=[0:T] and the obstacle is <= (R+K)42 
¢ Can be done by just checking boundary conditions and turning points. 
¢ Equivalent to solving for a cubic root: closed form. 
¢ Complexity linear in (Hobstacles) * (Hsetpoints) 


Obstacle 


Squared distance between the freeflyer geometric center 
and the origin of the obstacle sphere 


Turning Point 
t=j 


Turning Point 
t=i 


(R+K)42 
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Guest Science 


FSW APIs Overview 


¢ FSW uses ROS within Astrobee: Messages, Services and Actions 
define the internal API 


e Astrobee & Ground communication uses DDS and the RAPID 
framework for command and telemetry 


* Commands: 


* Commands are defined using XP-JSON schema, tools auto-generates 
RAPID command dictionary 


¢ FSW defined a ”ROS Command” mirroring the DDS command structure 
¢ Onboard Astrobee Guest Science or Ground Applications share the same 
command dictionary (some commands unique to one client) with either 
DDS or ROS transport 
° Telemetry: 
¢ Internal uses ROS Messages (using ROS messages when possible) 
e External uses DDS Messages (subset only, re-using RAPID messages) 
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Onboard Guest Science 


¢Guest science benefits from a quad-core processor 
running Android 


¢Interface with guest science hardware trough USB 
(possible to have special USB gadgets) 

¢Guest science runs as an Android app on the high 
level processor. 


¢Guest science apps communicate to/from outside 
a Freeflyer using the DDS protocol 


¢Guest science API consists of the ROS telemetry 
topics and the generic FSW “ROS Command” 


Platform Management 


Software Update Overview 


¢ FSW is deployed on 4 computers (Astrobee + Dock) 
running Linux and Android 


¢ Astrobee contains 7 distinct microprocessors with custom 
firmware + several microprocessors with COTS firmware 


¢ All paths for on orbit updates have been identified 


¢ PAD provides all the physical connections to implement 
these updates 


¢ Software deliverables includes: 
¢ Custom firmware(s) 
¢ Adapted Kernels 
¢ Linux and Android Operating Systems 
¢ FSW Dependencies 
¢ FSW code 


Astrobee Custom Firmware List 


Firmware Board Type Update Path 


Dock control firmware PIC32MX795F512H Dock Processor via I2C 
EPS firmware PIC32MX795F512H LLP via I2C 

PMC firmware PIC32MX795F512H LLP via I2C 

Speedcam laser firmware unknown ground harness only 
Speedcam velocity 

firmware ARM Cortex M4 LLP via USB 

Signal lights firmware PIC32MX795F512H LLP via I2C 


PerchArm firmware dsPIC33EP512MC806 MLP via Serial over USB 


Astrobee Software Categories 


Software Board Type Update Path 


Wandboard Kernel 
Inforce Kernel 


Linux Base OS 


Android Base OS 
FSW Linux 
Dependencies 


FSW for Linux 


FSW for Android 
dock software 
repository 


Wandboard Dual, Dual 
core i.MX6 

Inforce, Quad core 
Snapdragon 805 
["Wandboard, 'Inforce’] 


Inforce 


["Wandboard’, 'Inforce’] 
["Wandboard’, 'Inforce’] 


Inforce 


Wandboard 


Ethernet from Dock using 
Recovery 


fastboot over USB from LLP 
fastboot (Inforce) or recovery 
(Wandboard) 


fastboot using USB from LLP 


apt using Ethernet from Dock 
apt using Ethernet from Dock 


adb over Ethernet from MLP 


rsync over Ethernet from ground 


Software Update Methods 


¢ Base system (Kernel + OS) are flashed using: 
¢ Uboot (Wandboard boards, Linux) 
¢ fastboot (Inforce boards, Linux and Android) 
¢ FSW dependencies are delivered as Debian packages 
¢ FSW itself also delivered as Debian package 
¢Dock computer act as Debian repository 
¢ Only one copy from ground to ISS 
¢ Benefit from Debian “apt” toolset for safe upgrade 
¢ Filesystem uses OverlayFS 


¢ Permanence of a valid OS and software 
¢ Allow temporary configuration changes while running 


Localization 


Vision Algorithms 


¢Four MLP vision nodes send observations 
to the Pose Estimator: 

¢Sparse Mapping : runs for regular navigation, 

provides absolute position within the ISS map 


¢Visual Odometry: velocity and maintain pose 
when no features are available 


¢ Handrail Detector : 
only runs for perching 


¢ AR Tags : only runs for docking 


Optical Flow to Visual Odometry 


¢ EKF update is same as than with optical flow 
¢ 16 frames are retained instead of 4 


¢ Selected observations are used rather than last 4 
frames, and always keep oldest visible feature frame 


¢ Benefits: 
¢ More stable localization in nominal conditions 
¢ Resilience to loss of map features (unmapped, 
obstruction, light, ...) 
¢ Problem: covariance matrix size is (21 + 6 * 
augmentations)*2, increase from 4 to 16 is 576% 
increase, EKF had to be optimized by a factor 6 


“High-precision, consistent EKF-based visual-inertial odometry.” Mingyang Li 
and Anastasios Mourikis. International Journal of Robotics Research, 2013. 


Visual Odometry Performance 


eEKF is part of GNC, developed with Simulink. 
Despite optimizations, could not deliver the 
required performance. 


¢Computational intensive blocks have been re- 
written with C++ code using optimized libraries 


MathWorks “Optimized” FSW Hand Written C++ using | Improvement 
Simulink-Generated C Eigen 


of_residual_and_h 87.0s 20's 98% (43x) 
delta_state_and_cov 2255s 3.55 84% (6x) 


covariance_multiply 18s <2s 89% (~10x) 


Video of Visual Odometry 
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Lighting Conditions at the Day & Night Times on the ISS 


“Robust Visual Localization in Changing Lighting Conditions.” Pyojin 
Kim, Brian Coltin, Oleg Alexandrov and H. Jin Kim. Under submission. 


Original Algorithm 
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Forward Work 


¢ Build 2 ( CERT TR ) 
¢ Software update (platform management) 
¢ Freeze DDS API for Crew Control Station 
e Refine Guest Science API 
¢ Mobility (obstacle detection and perching procedure) 
¢ Finalize all subsystems controlling hardware devices 
¢ Improve Infrastructure (including simulation tools) 
¢ Build 3 ( Flight TR) 
¢ Complete platform management (file mgt. and transfer, 
etc. 


¢ Increase system reliability by extensive testing on Granite 
Lab and new Gantry (3D) facility 


¢ Adaptations to ISS specific environment 
¢ Implement UI 


BACKUP SLIDES 


Overall architecture 


Selected HW Architecture 


¢Three ARM processors to isolate guest code, vision 
based navigation and 100 Hz control loop 


¢Low Level Processor (LLP) — Linux, Dual core 
¢Runs high freq. EKF and propulsion control loop 


¢Mid Level Processor (MLP) — Linux, Quad core 


¢Runs absolute localization algorithms, obstacle 
detection, sequencer, communications 


¢ Heavy processing power used by vision 
¢High Level Processor (HLP) — Android, Quad core 
¢ Interface with Science Camera and Display 
¢ Encodes video with dedicated hardware 
¢Runs guest science code 


System Architecture (MLP+LLP) 
Obstacle — —_ 


Visual 
Odometry 
Sparse 
Sequencer Mapping Loc. 
Fault 


| MIN) DepthMap 
Executive (Perch) Loc. 


see states ae Uely (Petal 
Mobility Localization 


Pose Estimator 
Peripherals 


ROS Messaging 


Guest Science 


ROS Java: 


Limited or Full message set depending 
on level of guest science certification 


Communication Framework 


¢ Key factors for ROS 


Common Flight Executive (CFE) selection (vs. CFE): 


¢ Messages definition and 
Robotic Operating System (ROS) serialization support 


Mobile Robot Programing Toolkit (MRPT) ¢ Better service isolation 


Joint Architecture for Unmanned Systems ° Documentation & support 
WAUS) ¢ Library of Robotics 
Algorithms Available 


IRG RoverSW (SORA + RAPID) ‘ Key factors for DDS + 
Data Distribution Service (DDS) RAPID 


¢ Multiple Configurable 
ae Quality Of Service (QoS) 
Selected solution is hybrid of: ° ISS Tested + Heritage from 


- ROS for onboard messaging SmartSpheres 
- DDS for remote comm. 


Localization Design Drivers 


int eeiniceure ISS Wifi j=) Does not provide desired accuracy 
+ External Maps Beacons (passive/active) j——<=) Modifications to ISS / change dependent 


Stereo Vision “Metric” (shape) maps makes 
Robot Builds Eeeneo ena ae matching difficult 


Maps 


Monocular Vision j=» “Features” maps efficient to filter 


Localize anywhere on ISS US segment 
Minimize modifications to ISS Selected Solution (hybrid): 

Cope with changing environment - Build and update maps offline 
- Match visual features online 
(3 modes) for localization 
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Map of connected ISS Modules 
data from SmartSpheres projectO 


Platform architecture 


Processors and communication links 


Astrobee GN&C Subsystem 


Delta PTR3 Design Overview 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Maturity / Risk | Forward Work 


IMU High / Low 
Controller High / Low 
Estimator High / Low 
FAM High / Low 
Simulator High / Low 


Fault Management High / Low Implement faults from FMECA 


New/Changes from PTR3 


Estimator - 


Fault - 


Management 


Re-worked optical flow augmentation process to decrease 
drift when operating in an area with no mapped features 
Changes to allow for removing gravity from the IMU signals to 
allow for ground testing of 3 axis attitude control 


Identified baseline GN&C faults 


GN&C: Overview 
Design Drivers 


Parameter Linear Angular 
Requirement Requirement 

Maintain Controllability Up to 50 cm/s Up to 45 deg/s 

Max Acceleration 10 cm/s42 10 deg/s*2 

Pose Error (Nominal) < 20cm < 20 deg 

Pose Error (Assisted w/ AR tags, etc.) <2cm < 8 deg 


Use Vision based navigation 


GN&C: Overview 
Architecture Diagram 


Mid-Level Processor (MLP) GN&C MLP Simulator 


Computer Vision System Waypoint Cmd Sequencer Computer Vision System Waypoint Cmd Sequencer 


~ Optical Flow ~~ 
Mapped Landmarks 
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GN&C: Overview 
Architecture Diagram 


Mid-Level Processor (MLP) GN&C MLP Simulator 
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Integration with FSW 
¢ Matlab/Simulink models ARE the source code 


Vehicle Dynamics 


¢ GN&C SW components are auto-coded and IMU 


Propulsion Module 


imported into a single high priority ROS node Environmental Model 


GN&C: Software 
Estimator (EST) 


10.5 Hz (when available) Mapped Landmark\AR Target Feature Data 


Optical Flow Feature Data 


Mid-Level 
Processor 


Augmented state data 


Registration Pulse : 
g State & Covariance. 


IMU 
(Acceleration\ 
Body Rate) 


State & Covariance 


State Estimator 


Total of 45 states: 15 core states, 6 mapped landmark, and 24 optical flow augmented states 


iss iss iss iss iss 
x(t)=[ q b, VOD, P Com CML Chor. C.0F 4 Coors Coors | 
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GNC: Software 
Estimator (EST) 


¢Optical flow augmentation management 
logic changed to retain the oldest 
augmentations that contain features that are 
still visible 


¢ Retaining the oldest augmentations reduces drift 
and improves accuracy when operating in areas 
with poor map coverage 


State of EKF at 
time of oldest 
pictures that still 


State at time of 
most recent 
picture 


contain visible 
features 


OF 
Augmentation 


GN&C: Software 
Estimator (EST) 


¢Gravity removal done by using VisualEyez 
attitude estimate to calculate body frame 
gravity vector, then subtract from IMU 
measurement 


9.81 m/s 


GN&C: Simulation 


Current and Planned Uses 
> Development of controller and estimator 
> Software testing 


> Control robustness analysis 
(linear analysis and Monte Carlo testing) 


> Trade study analysis tool 
> Evaluation of sortie scenarios 


> power consumption evaluation 

> Sound level histogram 

> time to execute 

> Max required rates and accelerations 


> Requirements verification 
(where ground testing is not possible) 


Planned Future Testing 


¢Granite table goniometer testing 

¢ Allows testing in different orientations 
*Gantry testing 

¢ Allows testing 6-DOF system 


Monte Carlo Analysis: Docking 


Cup 1 Cross Track Error : Mean+3sigma value = 10.5402 Millimeters 


Tsk He an,  DOCking Scenario repeated 873 
times varying noise parameters, 
noise seeds, alignments, and 
uncertainties. 


ach bin 


Probability of being in e: 
° 
* ‘ 


Cup 2 Cross Track Error : Mean+3sigma value = 9.8885 Millimeters 
T T 


6 
Millimeters Bins 


Scenario only showed errors large 
enough to fail docking in a handful 
of scenarios (mostly due to large 
position or alignment errors of the 
Dock Cam). 


Probability of being in each bin 
2 § 2 
8 8 


2 SSS SSeS SS se ee ee 


could reject suction force 
from dock cooling fan and 
from propulsion system 
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Astrobee Perching Arm 


Design Overview 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Arm High / Low 
Gripper High / Low 
Controller board High / Low 
Software High / Low 


Payload Attachment Mechanism — High / Low Minor design updates 


New/Changes from PTR3 


Design - Aesthetic design updates for cable routing and appearance 


Hardware - New motors for both arm joints and gripper 
- New torsional springs for gripper 
- New silicone rubber pad for gripper 


Avionics - New load switch and current limiter for gripper motor 
- New level shifter to resolve impedance matching issue 
- New connector boards for arm distal link and gripper 


Software - New firmware for arm motors 
- Update MLP-Perching Arm ICD 


Snapshot of Hardware 
Progress 


wd ™ oa 


Stowed Configuration Stowed/Deployed Configuration 
(diagonal view) (top view) 


Component 


Arm Proximal Assembly Arm Distal Assembly 


Arm Base Assembly Gripper Assembly 


Captive Screw — 2X 


Gripper Tendon — 2X 


Torsional Spring — 6X 


Gripper Motor 


Opened Configuration Closed Configuration 


Mass 


Component Mass [g] Comment 


2 x motors for pan/tilt joint 

16 x M2-6 bolts, 2 x M3-10 bolts 
Arm 

Ultem 9085 density = 1.34 g/cm? 


_Spring [24 6 x torsional springs 
einer 4x binding posts 
2 x #2 bolts and 2 x nuts 


_haliseover_—_1.8_ 165.7 
Stal 


Controller Board 
Total 733 | 1.62 Ib 


¢ The mass of P4C perching arm is 460.7 g (1.02 Ib) including wires. 


Arm Motor 


¢ Robotis Dynamixel XM430-W210-R 
¢ Dimension: 28.5 mm (1.12 in) 
x 46.5 mm (1.83 in) x 34 mm (1.34 in) 
° Weight: 82 g (0.18 Ib.) 
¢ Input voltage: 10 V— 14.8 V 
* Gear ratio: 210:1 
¢ Stall torque: 3.0 Nm (at 12 V) 
¢ No load speed: 77 RPM (at 12 V) 
¢ Resolution: 0.088 ° 
¢ Set position/velocity/acceleration, provide present current 


¢ Enable/disable torque, provide present temperature, limit highest 
operating temperature, etc. 
IV] [FFREQ-934] The Perching Arm shall pan 90 degrees in 15 seconds. 


IV] [FFREQ-935] The Perching Arm shall tilt 90 degrees in 15 seconds. 


IV] [FFREQ-936] The Perching Arm shall have joint angle resolution of 1 
degree. 


Gripper Motor 


¢ Pololu Micro Metal Gear-motor 
¢ Dimension: 10 mm (0.39 in) x 12 mm (0.47 in) x 30 mm (1.18 in) 
¢ Weight: 9.3 g (0.02 lb.) 
¢ Input voltage: 12 V 
° Gear ratio: 298:1 
¢ Stall torque: 0.49 Nm 
¢ No load speed: 100 RPM 
¢ Resolution: 0.1 ° wonton 


Block Diagram 


Payload Connector Perching Arm Avionics 
4 - 6 V Regulator/ 


Current Sensor Gripper 
(LM22670/MAX4372) Motor Driver 


Payload (MC33926) 


11 V Regulat 
Voltage eeulatoty 


Current Sensor 
(Battery (LIM22670/MAX4372) 
Voltage) 


3.3V 
Regulator 
(TPS62162) 


Current 
as Limiter 
(MAX921) 


Middle-Level USB-Serial ii le cl i: 
Processor Converter 
(USB 2.0) (FT231) 


Level Shifter 
Se (TXS0102) 


Microcontroller 
(dsPIC33E) 


Temperature Level Shifter cou Proximal 


cei (TXS0104) peel Arm Motor 


Distal 
Arm Motor 


Gripper 
Motor 


°LTC4412 


Load Switch 


Perching Arm Avionics 


6 V Regulator/ 
Current Sensor 


4_(um22670/maxa372) 


11 V Regulator/ 
Current Sensor 
= 4 (LIM22670/MAX4372) 


3.3V 
Regulator 
(TPS62162) 


USB-Serial 
Converter 
(FT231) 


Microcontroller 


Temperature 
Sensor 
(ADT7410) 


(dsPIC33E) 


Load Switch 
(LTC4412) 


Gripper 
Motor Driver 
(MC33926) 


jomeoeeeeeeee 


POCO E EEE Ess | 


Current 
Limiter 
(MAX921) 


Level Shifter 
(TXS0102) 


| Level Shifter 
(TXS0104) 


COMM 
Transceiver 
(MAX485) 


¢ Switch gripper motor voltage between 6V and 11V 


3V3 


GRIP_PWR_EN< 


tivo 
Si4427BDY S44278DY 
8 1 1 8 
a: LET o2 Ltt 
7 7 
5 
3V3 
R6, 
70% 

4 


<~™}11V_LS_STAT 


6Vv0 


Si4427BDY 
8 1 


3v3 


70k 
<}6V_LS_STAT 


61 


tuF 


MGRIP_PWR 
> 


Ree 


10k 


Perching Arm Avionics 


6 V Regulator/ 


(MC33926) 


Current Sensor . Gripper 
1 {tm22670/Maxa372) Load Switch |) actor Driver 
(LTC4412) 
11 V Regulator/ 


H 
Current Sensor : 
4 (LM22670/MAXx4372) = 


= : 3.3V Current 
Regulator Limiter 
(TPS62162) (MAX921) 
es 


USB-Serial 
seeee9 Converter 
(FT231) 


“som eeeeeee 


Level Shifter 


(TXS0102) 
Ld 


Microcontroller 
(dsPIC33E) 


ag ret 4 Level Shifter |. Sane: 
(ADT7410) (7XS0104) (MAX485) 


°MAX921 


¢ Disable gripper motor power when gripper motor 
reaches 80% of stall current 


w3 


]MFB (from motor driver) 


{2 second pulse} 8 
aeite tla 
Cc? 1.0u 
Bm Cc 
O.tu 
R? 
* 


——=—=—=—{ >» Gripper_STAT (lo micro-controtier) 


{> MEN (lo motor driver) 


Gapper_EN (trom micro-controtier) > + 
| 


Level Shifter 


°TXS0102/TXSO104 


Perching Arm Avionics 


Current Sensor 


6 V Regulator/ 


g=_(um22670/maxa372) i 


11 V Regulator/ 
Current Sensor 


7 
== (LIM22670/MAX4372) 


Load Switch 


Gripper 
f= Motor Driver 


3.3V 
Regulator 
(TPS62162) 


USB-Serial 
¥ Converter [==" 
(FT231) 


Temperature 
Sensor 
(ADT7410) 


Microcontroller 
(dsPIC33E) 


(LTC4412) 
™ 


| Level Shifter |, 


(TxS0104) 


(MC33926) 


Current 
Limiter 
(MAX921) 


Level Shifter 
(TXS0102) 


cOoMM 


" Transceiver 


(MAX485) 


¢ Translate voltage-level of arm motor signals 
and gripper encoder feedback signals 


¢ Has an internal 10-kQ pull-up resistor 


3V3 


5Vv0 


c33 
0.1uF 


UART2 TX 5VO0 
UART2 RX _ 5V0 
UART2 DIR _5V0 


UART2 TX 3V3 
UART2 RX 3V3 
UVART2 DIR _3V3 


TXS0104 OE 


R46 
10k 


3Vv3 


MENCA_3V3 
MENCB 3V3 


5V0 


c3 
0.1 


MENCA_5V0 
MENCB 5V0 


= Level Shifter 


1 
uF 


Arm Motor 
COMM Transceiver 


°MAX485 


Perching Arm Avionics 


7 
== (LIM22670/MAX4372) 


Current Sensor 


6 V Regulator/ 


11 V Regulator/ 
Current Sensor 


= _(LM22670/mMaxa372) Load Switch 
: (LT¢4412) 


Gripper 
f= Motor Driver 


3.3V 
Regulator 
(TPS62162) 


¥ Converter 


USB-Serial 


(FT231) 


Temperature 
Sensor 
(ADT7410) 


Microcontroller 
(dsPIC33E) 


(MC33926) 


Current 
Limiter 
(MAX921) 


Level Shifter 
(TXS0102) 


| Level Shifter |, 


(TXS0104) 


COMM 
Transceiver 
(MAX485) 


¢ A low-power transceiver for RS-485 communication 


¢ Allow to transmit up to 2.5Mbps 


5V0 


R47 
10k 


UART2_RX_5V0 


UART2_DIR_5V0 


UART2_TX_5V0O 


Astrobee Thermal Subsystem 


Delta PTR3 Design Overview 
1 February 2017 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware. 


Maturity / Risk | Forward Work 


Core Module High / Low None, Cert Unit Testing 
Propulsion Blower Motor High / Low None, Cert Unit Testing 
Nozzle Servos High / Low None, Cert Unit Testing 
Perching Arm Servos High / Low None, Cert Unit Testing 
Perching Arm Gripper Motor High / Low None, Cert Unit Testing 
Dock Avionics High / Low None, Cert Unit Testing 


Dock Linear Actuator High / Low None, Cert Unit Testing 


New/Changes from PTR3 


Design 


Hardware 


Removed LLP Heatsink, Wires bundled to minimize airflow 
pressure resistance in core; 


No Thermal Fuses; Added Perching Arm gripper DC motor 
current limiter; Nozzle servos covered; 


Central Module 

¢ Avionics Boards 

*  Fore/Aft LED Lights 

* Touch Screen, Status Lights, Etc. 


Top Forward Module 
¢ Laser Pointer, Cameras, Etc. 


Prop Module (2) 

¢ Impeller Motor 

* PMC Board 
Nozzle Servos 


Perch Arm 
¢ Arm Controller Board 
¢ Joint Servos 

Gripper DC motor 


Dock 


Forced convection (fans mounted in core). 

Current Limit, Temp Sensors, Conduction to aluminum frame / forced convection. 
Conduction to forward panel and frame. Heat rejection to central core (forced 
convection) and environment (conduction/convection/radiation). 


Low power and/or infrequent operation: Conduction to panel and frame. Rejection 
to central core and environment. 


Conduction to aluminum plenum floor; forced air rejection via nozzles. 
Conduction to plenum floor. Heat rejection by forced air in central module. 
Conduction to structure. Rejection via plenum air flow. 


Conduction to structure; rejection via conduction/convection/radiation. 
COTS Firmware Temperature limit; Conduction to structure; rejection via 
conduction/convection/radiation. 

Load Switch and Current Limiter 


¢ Avionics Boards and DC-DC converters Forced convections (fan mounted on Dock face) 
Linear Actuators COTS Firmware Current Limit; Conduction to structure; rejection via 


conduction/convection/radiation. 


Batteries (4) Low thermal power. Conduction to structure; rejection via core forced air. Direct 
rejection to environment via conduction/convection/radiation. 


Central Module Heat Sources 


exhaust vent ed fe ieee et 


Board 5 


isBoard 4 
biank| 


Board 3 forward 
Board? panel 


blank | 
a BOA 1 3W 
LED 


¢ Most of the heat is produced on Board 5 (MLP, HLP). 


aft panel 


¢ Heat produced by Boards 1 and 3 is negligible. Flow to those 
boards can be restricted: Plastic strips attached to board 
stand-offs. However, this would increase the overall AP. 


¢ Forward and aft LED lights: Heat sink to aluminum frame; 
frame cooled by air flow, thermal radiation from 
top/bottom/front/back panels. Finned heat sinks can be 
used as well. 200 


Current Design 


Additional Core Air Inlet 
May be deleted if unnecessary 


Cooling Fan Module 
inside view) 


Core Air Outlet 


a Cooling Fan Module 
(downstream view) 


= 


MLP/HLP 
Heat Sink 


Core Air Inlet Fan Exit 


201 


Core Air 
Inlet 


(Forward) 


Core Air 
Inlet 


Cooling Fan 
Module 


Core Air 
Outlet 


(Aft) 


Core Air 
Outlet 


Core cooled by forced air convection, driven by two aft-mounted 


cross-flow fans. 


202 


Left Side Baffle Right Side Baffle 


Baffles prevent air flow circumvention of avionics boards. 


203 


Thermal Management 
Propulsion Modules 


¢ Mount prop motor to aluminum floor of plenum. 
¢ Max air speed in plenum is ~ 31 ft/s (near fan shaft at center of plenum). 
e At max motor power, must reject 3 W (based on efficiency of motor). 


¢ This requires a turn-over of ~ 1 CFM to remove the heat from the plenum (with the 
exhaust temp well below the max touch temperature). 
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Perching Arm Servo, 
Gripper DC Motor, Dock Actuator 


¢Perching Arm Servo 


¢ Measured Continuous Operation Temperature 
less than 40°C 


¢ Temperature Limit Set 35°C in Firmware for Stall 
¢ Tested Temperature Limit Shutoff-Passed 
¢Gripper DC Motor 
Added 80% Current Limiter (previously discussed 
in Perching Arm Design Overview) 
¢ Dock Linear Actuator 
Current Limiter for Stall Condition 


Dock Air Flow 


DOCK AIR INTAKE 


DOCK AIR EXHAUST 


WITH DEFLECTOR eee 


rated to 12.7 CFM 
3000 RPM 


DC Blower 
75X75X30 


DOCK AIR EXHAUST IF DEFLECTOR IS REMOVED 


Safety Features 


Cooling fans always on—no software control (firmware). 


lf forward/aft LED lights temperature limit exceeded, hardware 
over temperature power cut-off engages. 


Forward/aft LED lights recessed from panels, not touchable. 


If processor temperature limit reached, processor operating 
system throttles power. 


Fail-safe: If system temperature sensor limit is exceeded, 
hardware over temperature cut-offs entire system power. 


Astrobee Dock Mechanical Subsystem 


Design Overview 


Design Maturity 


Maturity / Risk | Forward Work 


Dock housing High/Low Select dock color 
AR Targets Med / Low Change attachment mechanism and 
target size 


Bonding Strap Med / Low Attachment location 


New/Changes from PTR3 


New / Changes 


Dock 


Dock 


Dock 


Berth post 


Berth post 


Dock mounting 


Reduced the overall width of the Dock due to removal of 
battery charger. 


Added an additional patch panel to accommodate more 
electrical components 


Added air vent deflector to direct thermal exhaust 
New Modular attachment Bracket for Tilt and Non-Tilt Option 


Lances change from horizontal to vertical alignment 


Added additional attachment points for mounting brackets 
(velcro / seat track) 


ISO View — Dock 


Dock Board 


Light Indicator 4X 


Air Vent da Small Breaker 3X 


ON/OFF Main Breaker 
Switch Guard 


DC /DC Power 
Converter 


Wand Board 


Handle 2X 


Cooling Fan 


Cooling Fan Screen 


Filter 
AR Target RJ-45 
Connector 
Aluminum Power Connector 
Structure . 


Adjustable Attachment 
Bracket AR Free Flyer Dock 
Interface 2X 


Patch Panel Covers are Shown Transparent For Clarity 


Dock Air Flow 


DOCK AIR INTAKE 


DOCK AIR EXHAUST 


WITH DEFLECTOR eee 


rated to 12.7 CFM 
3000 RPM 


DC Blower 
75X75X30 


DOCK AIR EXHAUST IF DEFLECTOR IS REMOVED 


Dock 
Front and Side View 


NOTE: Dimensions are in inches 


ISO View 
Dock —Flyer-Human 


Dock 


Front View With no attachment Brackets 


Free Flyer Dock Interface 
Front Side 


Interface Plate Shown Transparent 


For Clarity 
(3.75) a 
i) 


Captive Screw — 4X 


500+ 


7 


ta 
TT 
_ 
O. 
<< 
i 
Y 
“h 
aa? 
= 
= 
ta 
Ty 

ol 


Lance -2X 


Connector 
20 Spring Loaded Pins 


Total reaction Force = 2.7|b 


4 Magnets Located 


Behind Interface Plate 


Interface Plate 
Total Holding Force = 10.9lb 


Free Flyer Dock Interface Plate 


Magnet 
KJ Magnetics 


Back Side 


Linear Actuator 


2X 

L12-1 FIRGELLI 
30mm Stroke 
210:1 


LA2 Specifications 


Peak Power Pome 


sO} 


LIN @ Limm/s JIN @ Gmm/s 458 @ 2. Sms 


Peak EMficency Point ON e@ lomm/s 12N @ Briss 18N @ 4mimn/s 
Maa Speed (no toad) 23mm/s L2mmy's Smm/s 
Mas Force 12N 23N 45N 
Back Drive Force 45N BON 150N 
Strobe ( 10 mm Orn 50mm oo 
Mans 288 Me 406 Soe 
Repestatity 44 NAc) 2. lb mm 210.2 mm 20.3 een £0. $ mm 
Max Sate Load SON aon nN 15N 
Chased Length hote to howe olmm 82mm 302mm 1$2mem 
input Voltage O7.5V, 6 VOC Rated 0-13. 5¥, 12 VOC Rated 
Stat Current $50mA @ bv 220mA @ 12V 
Operating Temperature t0"C to +50°C 

Storage Temperature -30°C to «70°C 

Duty Cycle 20% 

Lfetme 20,000 strokes 

Audible Noise 5508 @ 45cm 

ingress Protection os 


Feedbact Potentorneter 
(a+ 

Larit Switcives s 

Standby Current -1/-R 


L/BW Non-Buftered 1 kf) -208f) Potentiometer 


Max. Current Leakage: Bud 
7 lms 3.3mA 


Astrobee Dock Avionics 


Design Overview 


Design Maturity 
Dock Avionics 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 


Maturity / Risk | Forward Work 


Controller board High / Low New 12C lines 
DC/DC board Low / Med New board 
Dock adapter board High 

Dock Processor High New Wandboard 


Actuators High 


New/Changes from PTR3 


DC/DC - Reverting back to our original design 
Smart Dock - New Dock Processor 


COTS Charger - Removed from dock 


Dock Avionics Diagram 


ISS Network 


120 VDC from ISS 


Actuator _ 
Dock C__ = 
Adapter | Ethernet | 
| Switch —— FC 
24V | Power 
Charging Ethernet 
Dock Protection 
Adapter | one 
Actuator | 


Se 


@ 3-A Circuit breaker 


eSame Processor as LLP 
¢FW updates for Dock PIC 


¢Remote wake up of 
Astrobee 


¢Publish Dock telemetry 
¢Ubuntu 


Astrobee GDS Subsystems 


Design Overview 


Components 


¢Control Station 
«Provide GUI for a remote user to command and 
control Astrobee during nominal operations 
¢Ground Server 
eStore Astrobee data and make it available to 
external users 
eEngineering Tools 


¢ Provide tools for debugging and advanced 
engineering support 


Architecture Diagram 


UOP/PS-120 
Docking Station 


Payload LAN 


Control Station 
(EXPRESS Laptop) 


Free Flyer 


ISS Data 


Storage (NAS) 


Control Station 


Engineering fi. Ground 
Tools Network 


Ground Data 


Storage ISS Infrastructure 


a+ ——> Physical Interface 


4+ Data Interface 


Astrobee System —+———> Electrical Interface 


Design Maturity 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Maturity / Risk | Forward Design Work 


Plan Editor High 
Plan Controller High 
Teleoperation High 
Guest Science High 
Ground server Med / Low Specify server 
Data Archive Interface High 


Engineering Tools High 


New/Changes from PTR3 


The Astrobee team is aiming for CDR-level of maturity for all system hardware, 
however there are some known design gaps described below. 

All system software is less mature, and is not at CDR-level of maturity. 
Software builds are expected to continue through on-orbit testing. 


Faults Display name of faulty subsystem, no display for warnings 
Guest Science Split Guest Science into Crew tab and Advanced Tab 
Control Station GUI Added buttons to allow access to needed functionality 
Ground Server Verified TReK connection to Ground Server is possible 
Config Files Repository of config files 


SmartDock Support for Wake/Hibernate via SmartDock 


Control Station 


Control Station 


Description Crew eT cel U late, PANS ge) of -1-) 
Controllers Engineers 


Plan Editor Create and edit Plans 
Plan Controller Run Plans and monitor execution X X X X 
Teleoperation Send individual commands X X X X 


Guest Science Run Plans on up to 3 Astrobees 


Advanced Guest Run Plans and control APKs on up to 3 
Science Astrobees 


Advanced Modify and monitor advanced settings X X 


Plan Editor 


Plan Editor Rum Plan Teleoperstion 


GPS 1Sdunl6 20.450 


. Interacteve Plan Veewer 
Plan Editor 
Plan Name és 
Estimated Duration 02:12:19 


Vabdstion Not Validated {Validate} 


Plan Step Duration 

ae 
0 Staton 
1 Station = . 
1-2 Segenera Vabdshon Failed a 
2 Station 
2-3 Segeners 
3 Station 


Li st V j CW A Potentsal colksion in Segment 0-1, Please move Station 0 or Station 1 
3-4 Seqenent 
4 Sabon \ 
— of Plan nt 


5 Staten 


5-4 Segrnert 


6 Sabon 


“Sarg 


Add Delete Add via Jd View 


0 Station 
Location Based Coordinate Based Bookmarks Commands 


743 


3D model 
of Plan 


0 + Pitch 0 + Ya 0 2 deg 


Jgnore Onertation 


Tolerance go] ™ 


Element 
editor 


Y Drag to Traralete Drag to Rote 


0:00:00 Message goes here 


Run Plan Tab 


File Edit View Help 
Run Plan Teleoperation Guest Science 


FreeFlyerA | Comm @ Control OW@DW-Windows7-32 Batt a4 


Health and Status Details Select and upload 
Plan, and control 


Operating State Plan Execution . ~ 
Mobility State Flying ? mre Plan execution 
Operating Limits Default_Safeguard 

Plan ExamplePlan 

Plan Status Executing 


Plan Live Telemetry Live Images Science Camera 


Total Elapsed Time 00.00.43 


Plan Step Duration Success 


4 ExarmnplePlan 


2-3 Segment 

3 Station 

3-4 Segment Monitor 

4 Station 

4-5 Segment plan 

5 Station execution Model of 


loaded 
plan 


18:19:41 FreeFlyerA: Run Plan Pending ... 


File Edit View Help 
Run Plan Teleoperation Guest Science 


FreeFlyerA *| Comm @ Control OWODW-Windows?7-32 


Health and Status 
Operating State Ready 
Mobilrty State Stopped 
Operating Limits Default_ Safeguard 
Plan 
Plan Status idle 


Configurable Teleop Commands 


Gripper 


Idle Propulson 


Payload A 

Flashlght Bnghtness 

Front 7 | High bd 
Data Type Action 

Immediate + | | Download ’ 


01:44:24 FreeFlyerA: Unknown Command Completed 


Manual Commanding | Perching Arm Docking 


Initialization Manual Inputs 


m 


Wake Aft O5 > Fwd 


Po ‘ "] + She 
Grab Control ort 5 Mbd 


No Bookmark Selected . Ovhd ¢ 00 » Deck 


Live Telemetry Live Images Live Video 


Pach ¢ 


00 » 


GPS 12Jant7 014627 


Commands 


Allow Lateral Motion 


Override Obstacles 


Override Keepouts 


Teleoperation Tab 


File Edit View Help 
Run Plan Teleoperation Guest Science 


|FreeFlyerA *| Comm @ Control DW@DW-Windows7-32 Batt 62 Docking Station @ | GPS 14Jant7 00:11:04 


—) | Manual Commanding | Perching Arm Decking 
[ \ 


Health and Status Details 
Initialization Manual Inputs (Degrees) Options Commands 

Operating State Ready 

Mobility State Perched 

Operating Limits Default_Safeguard Wake Pan « -20 * deg Reacquire Position | Unperch 

Plan 

Plan Status idle Grab Control Tit « 120 + deg fe: ” [ Pan and Tilt ] 
) 

Stop 


Configurable Teleop Commands ve ay | Live Inoges| Uve Video 


Gripper Open oe < 
iin ’ 
Idle Propulsion Idle = wi 
is 
Payload A On NB 5) 
Flashleght Bnghtness 
Front 7 | | High ’ Set ASA 
Data Type Action Ne 
Immedchate + | | Download ’ Send 


00:08:16 FreeFlyerA: Arm Pan And Tilt -20, 120 Completed 


File Edit View Help 


Health and Status 
Operating State Ready 
Mobility State Stopped 
Operating Limits Default_Safeguard 
Plan 
Plan Status idle 


Configurable Teleop Commands 
Gripper 


Idle Propulsson 


Payload A 

Flashlight Bnghtness 
Front 7 | | High 

Data Type Action 
Immedhate >| | Download 


01:49:49 FreeFlyerA: Unperch Completed 


Docking Station @ | GPS 12Jani7 01:50:03 


: Initialization Manual Inputs Options Commands 
= Dock fotomottcaty 
Grab Control Dock Manually 
Stop 


Live Telemetry Live Images Live Video 


Open 
Idle e By, 
r 
. Y 
Set Q Q 
Send Reset View 
> Center on Bee 
Show Preview 


File Edit View Help 


Run Plan Teleoperation Guest Science 


FreeFlyerC | Comm @ Control nobody Batt 8 GPS 12Jani7 01:57:23 


Manual Commanding | Perching Arm Docking 
Health and Status Details . 


Initialization Manual Inputs Options Commands 


Operating State Ready 

Mobility State Stopped uton 
Operating Limits Default_Safeguard 

Plan Mi 
Plan Status Idle 


Details available 
from button on 
Health and 


Configurable Teleop Commands Status view 
Gripper per 

Idle Propulsion 

Payload A n 

Flashlght Brghtness 

Front 7 | | High ’ et 

Data Type Action 

Immedsate + | | Download ’ 


01:56:30 FreeFlyerA: Run Plan Completed 


Guest Science Tab 


5 Crew Control Station 
File Edit View Help 


Run Plan Teleoperation Guest Sci 


Checkboxes 
select Astrobees 
to command 


Docking Station @ | GPS 17Jani7 18:44:47 


Astrobee Selectio id Status 


Control Plan Status Health 


Idle oO 


Names of 
loaded 
Plans 


Status 
summaries 


Live Telemetry Live Images Science Camera 


onitor 

Astrobee 
positions in 3D 

window 


Command 
Astrobees 


18:41:36 FreeFlyerB: Grab Control 


Advanced Guest Science 


Pian Editor Rum Plan Teleoperation 


Guest Soence Advanced Guest Scrence Advanced Advanced2 Modeling Debugging 


Astrobee Selechon and 


Contro 


Love Telemetry Live Images Science Camera ence Telemetry 


Commanding for FreeFlyerd, FreeFhyer® 


Plans 


Stop 


Send Command 


ence gov.nats arc irg attrobee GrappingHock 


File Edt View Modeling Help 
Plan Editer Rum Plan Telecperation Guest Science Advanced Guest Science Advanced Advanced? Modeling Debugging 


so 


Triggered and 


*) Comen @ Controt nobody 


FreeFiyerA Operating Limits 


Select Operating Lents Conf 


Configure Data 


Name 
Profile Name 
Flight Mode 
Target Linear Velocity 
Target Linear Accel 
Target Angular Velocity 
Target Angular Accel 
Colhsion Distance 
Check Obstacles 
Check Keepouts 


Conkle ® 


Detailed Health 
and Status 


Rn Patna 


FreeFlyerA Power State 


Battery Total 1 
Voltage 2 
Current 2 


Not Triggered 


Faults 


00:00:00 Message goes here 


quraton 


Advanced Tab 


View and 
change 
Operating Limits 


10 rea!s 
10 ted/s/s 
is m 

true 


Detailed 
battery 
status 


Current (A) 
148 
Yes Yes 132 2.107 


Temp (C) 


Detailed 
component 
status 


FreeFlyerA Data to GDS 2 Configure 
Telermetry Current Freq (Hz) Change to (Hz) 

= aR telemetry 
pouben 5 | Set} 

8 ? 5 [sa] sent to 
comenstatus : 5 [sel Control 
dakState v7 5 [Set] Station 
Camera Streaming Reseluten FPS 
science No 600.490 [640.489 +)00 00 09 0.0 | Set] 
aniguien | =) 0 0.0 | Set| 
hazed «No [600.490 [60.400 ~)09 00 00 00 [Set] 
FreeFlyerA Data to Dink 
Download Data! Stop Data Download| Clear Data 
Disk Data Sure (G8) Disk Se (GB) 

Disk A 0.000002 

Disk B 0.000003 

Disk C 0.900003 

Disk D 0.000003 

Disk E 0.000005 

Ovsk F 0.000006 

Disk G 0.900005 

Topic Dowenbink Freq (Hz) 

RosTopecd Imenediate $0 
RosTogecl Imenediate 50 
RosTopec2? Imenediate 50 
RosTopec3 Oetayes 109 
RosTogecd Odlayes 

RosTopeS Delayed 

RosTopicé Oeleyes View and 


configure data 
saved to disk 


Configure Data 


Configuration Files 


¢ Config files facilitate changes 


¢When the Control Station is run in a new 
location: 
¢ ControlStationConfig folder is created 
¢ Default versions of the config files are copied in 
°A config file repo exists on the ground for version 
control (branches for separate projects, etc) 
¢Ground users pull from repo to update configs 


¢Astrobee Engineering scps config files to ISS 


Ground Data 


Crew Control 
Station 


Future Capability 
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Data Flow During Operations 
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Data Flows After Operations 


ISS 


Rosbag for delayed 
downlink (Samba) 


ISS Data 
Storage 


Rosbag for 


immediate Existing 


services 


downlink 
(TReK CFDP) 


Guest Science Location 


Guest 
Scientist 
Computer 


Web 


SSH 


Data 
Ground Data Archive 


Storage Interface 


Ames TI Open 


Data Flows After Operations 


e\When Astrobee is docked after a sortie: 


¢ Files designated for immediate downlink are 
transferred from Astrobee to the Ground Server 
via TReK CFDP 

¢ Files designated for delayed downlink are 
transferred to ISS data storage and downlinked 
via existing services at a later time 


Ground Data Storage 


¢Ground Server 


¢On Tl-Open to provide access to approved 
external users via LaunchPad 


¢Running Red Hat 6 and Apache 


¢Data Archive Interface 
¢ Web-based file listing granting read-only access 
to data on server. 


¢ Access control allows Guest Scientists to protect 
proprietary data 


Systems Engineering 


Delta Periodic Technical Review 3 
February 1, 2017 


Outline 


*Design maturity 


¢Key performance parameters (KPPs) and 
technical performance measures (TPMs) 


DESIGN MATURITY 


Hardware Design Maturity Overview 


Subsystem Maturity Maturity Forward work 
(PTR3) (now) 


Structure 


Human-robot 
interaction 


Propulsion 
mechanical 


Propulsion avionics 


Avionics 


Comm 

GN&C 

Perching Arm 
Thermal 

Dock mechanical 


Dock avionics 


70% 


40% 


60% 


80% 


80% 


90% 


90% 


70% 


70% 


80% 


70% 


90% 


100% 


90% 


100% 


90% 


100% 


100% 


90% 


100% 


90% 


100% 


2 Battery retention, camera recessing and bezels, iterate 


minor PAD issues. [Risk: glass safety / recessing] 


Improve strength, finalize soft goods components and 
impeller balancing. [Risk: collision safety / bumpers; lack of 
integrated testing during P4D; no noise update until cert] 


[Risk: collision safety / thrust limiting] 


Over current safety, robust firmware updates, iterate based 
on P4D issues (e.g. wire routing) 


Add retention levers 


AR target panel improvements; finalize surface finish 


Software Maturity Overview 


Processor Software maturity | Software maturity | Forward work 
(PTR3) (now) 


HLP/MLP/LLP 
EPS 


Propulsion module 
controller 


Perching arm controller 
SpeedCam [PX4FLOW] * 
Signal light controller * 
Dock controller 

Dock processor * 

Crew control station 


Misc. GDS / Enabling 
products 


40% 


80% 


60% 


70% 


40% 


0% 


70% 


0% 


70% 


30% 


60% Many areas 
90% Remote wake, crew control details 


100% 


100% 
80% Fault behavior 
10% Detailed design and implementation 
90% Thermal, interface with dock processor 
10% Detailed design and implementation 
90% Minor bugs, command coverage 


60% Identify full suite of support tools needed as 
conops maturity improves 


* Marked rows indicate new items since PTR3 — either new processors, or significant scope 


increase 


KPPS AND TPMS 


Parameter SPHERES Threshold Value Project Goal Corresponding Technical Performance Measure 
(Minimum success) (Full success) 


Max velocity 4 cm/sec 10 cm/sec 50 cm/sec N/A — Design will achieve threshold; challenge is ensuring 
reliability at high speeds. 

Max acceleration 10 cm/sec? 5 cm/sec? 10 cm/sec? N/A — Design will achieve threshold. Propulsion thrust is on 
target; acceleration performance now depends on mass. 


Measure angle & point +/-2 deg +/- 20 deg +/- 8 deg TPMs 5, 7 


Sorties supported with 1 1 3 N/A — Design will achieve goal 
peripheral ports 
ttsesson Pe ft _— 


test session 


ISS operational space 2mx2mx2m JEM, US Lab, and All USOS N/A - Design will achieve goal (modulo safety keepout zones 
Node 2 that might include Cupola, Airlock) 


[From IRG-FFO01-Astrobee-Project-Management-Plan] 


Technical Performance Measures 


ee ee Ce 


TPM1_ Flight Time (h) 


TPM2_ Mass (kg) 8 - 
TPM3 Noise @ Max Thrust (SPL dBA) 65 - 
TPM4_ Pose Estimation Error Translation (cm) X 20 2 
TPM5 Rotation (deg) X 20 8 
TPM6_ Pose Control Error Translation (cm) X 20 2 
TPM 7 Rotation (deg) X 20 8 
TPM8_ Navigation MTBF (h) 10 - 
TPM9 Max Computing Processor Load 100% - 
TPM10 Max Computing Memory Consumption 100% - 


[From IRG-FFO02-02-Astrobee-Technical-Performance-Measures| 


100% 


90% 
80% 
70% 
60% 
50% 
40% 
30% 
20% 
10% 


0% 


PTR2P4IR P4TR_ PIR3 


= Threshold Value 


=i Mass 


ie Flight time, position 
estimation and control 


== Noise 


—<— Computing 


Software-Driven TPMs 


¢Performance for some TPMs largely driven by 
software 
¢TPMs 4-10 (position estimation and control 
accuracy, navigation MTBF, CPU and memory) 
°Flight software final delivery will likely occur 
after hardware certification is complete 


°As we update the project schedule, we may 
stretch the maturity timeline for TPMs 4-10 
to reference it to software final delivery 


: wa [e)¢) [0 Update Approach TPM 
Accuracy 


Fron] maint) ewatchoniremesomine eae) [RT 
Nest) [esasena weehsoneR@ps [Me 


Control Error Low 
(cm) 


Control Error a Low 
(deg) 
CPU (4) 136 


TPM Status 


# TPM Thresh Desired Threshold Current best PTR2 Status PTR3 Status 
= with margin estimate 


TPM 3 | Noise (dBA) 62.25 | Insufficient Insufficient 
margin margin 
TPM 4 | Estimation Error (cm) L = 


CPU TPM 


Haven't formally re-evaluated this TPM, but 
may no longer have sufficient margin 


¢Visual odometry improvements increased 
CPU consumption in the estimator loop 


¢Flight software team does not consider this a 
major concern 
¢Control loop is reliable, in practice 


¢ Optimizations are available if needed to increase 
efficiency, but many other reliability 
improvements take priority for now 


Noise TPM 


At PTR3, we reported the TPM estimate was 64.5 dBA, too close to the threshold requirement of 
65 dBA; the margin should have been 3 dB 


Our plan was to start on further acoustic testing and possibly design rework to regain noise 
margin 


Further testing showed that the noise measurements were very sensitive to details of 
experimental setup 


* We switched modes on our sound meter per advice from JSC acoustics experts, and saw reduction from 
64.5 dBA to 62.25 dBA (almost on target) 


* There’s also still debate about how to position the microphone so as to experience the “worst-case noise” 
but not have the sound measurement thrown off because the microphone is directly in the air flow path 
Completed minor design rework to reduce noise: 


* We evaluated several COTS servo models for the nozzles, trying to find one that was both quieter and 
rugged enough to survive extended stall conditions if a nozzle was jammed. We ended up with a model 
that is very rugged, but not much quieter. 


* We added isolators between the nozzle servos and the plenum body, to avoid the plenum acting as a 
sounding board to amplify the servo noise. 


¢ We haven’t had a chance to evaluate the resulting improvements yet. 


Proposed forward approach: 


* Acoustics appear to be on target for now, but some risk that prop module structural changes will increase 
the noise level 


¢ The new structure may act as a sounding board, or simply absorb less noise than the old foam lid 
¢ Next full acoustic test will be on cert unit propulsion modules 
¢ If rework is needed, there will likely be a significant schedule impact 


Mass TPM — Post-PTR3 Review 


e At PTR3, we reported the mass TPM had negative margin 


(7.0 kg > 6.0 kg) 


¢ We developed the following plan: 


Accept the mass slip and relax mass 
threshold requirement to 8 kg, 
restoring healthy margin 


(Optional) Execute known 
lightweighting opportunities, possibly 
reducing mass below 7 kg estimate 


(Optional) Increase propulsion module 
rated max thrust to restore 
acceleration at or near 10 cm/s? 
(without changing hardware design) 


Done 


Mostly not 
executed 


Not 
executed 


The mechanical team spent almost 100% time between PTR3 and 
today making the design close functionally, particularly finishing 
significant prop module changes. Most of the lightweighting 
options were not executed due to lack of time. 


There are three main constraints on max thrust: (1) the physical 
capability of the power system and motor, (2) limiting kinetic 
energy in a collision, and (3) noise limits. Recent testing shows 
there is plenty of headroom for (1), but (2) and (3) still require 
further testing before we could promise increased thrust. We are 
getting closer to being able to run the relevant tests, and will 
continue to assess whether this opportunity exists. 


Mass TPM — Recent Update 


¢ At PTR3, we reported that there was a risk of further mass 
growth, estimated < 0.5 kg, due to low design maturity of some 
components, particularly the propulsion modules 


¢ Since then, we actually saw mass grow from 7.0 kg to 8.7 kg, 
significantly exceeding the new mass threshold set at PTR3 


¢ Where the growth came from: 

¢ The largest hardware design change was replacing the fragile foam 
plenum lid with a more rugged structure 

° Our tight schedule during that redesign forced straightforward design 
choices such as solid panels that have sub-optimal strength-to- 
weight, but are easier to work with 

¢ Constraints of supporting crew servicing and minimizing redesign of 
other parts of the prop module led us to a design that’s probably 
more complex than it needs to be, further driving up the mass 

° EN everyone was surprised how heavy this design worked out 
to be 


Mass TPM — Forward Plan 


¢ Our baseline plan is to accept the new mass estimate 


¢ Design maturity is much higher now, so we don’t expect this to 
happen again 
¢ Relax mass threshold requirement to 10.5 kg (8.7 kg + ~15% 
margin) 
¢ Increased mass will reduce max acceleration to 5.7 cm/s2, assuming 
we don’t increase max thrust 
¢ Increased mass may also require reducing max velocity below 50 
cm/s to mitigate collision hazard, pending further testing of 
SpeedCam and bumpers 
¢ We have other mitigation options: 


¢ Old lightweighting opportunities still exist, and the redesigned prop 
module has more low-hanging fruit 


¢ May still be able to increase rated max thrust to restore acceleration 


* But Saas d we don’t have time to execute these options without 
schedule relie 
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Integration & Test 


Overview and Status 


Integration and Test Status 


¢Prototype 4D 
¢ Created for Additional Risk Reduction 
° All flight-like core, repurposed propulsion 
module, ABS top-forward module 
¢ Integration Complete 
¢ Testing in progress 
¢Certification Unit 
¢Cert Unit Integration Procedures beginning 
review 


«Continuing coordination with Code Q (Quality 
Assurance) 


Facility Prototype 4D Certification — 


Granite Lab 


MGTF 

EMI/EMC facility 
Engineering Evaluation 
Lab 

Off-gassing White Sands 


Anechoic 


JSL at JSC 


Vv Ames 


V Ames 


Vv JSC 


v JSC 


Prototype 4D Risk reduction 


New Material 
manufacturing and 
tolerances 


Gripper Performance 


Sensor Placement 


Crew Serviceability 


Wi-fi Interference 


Avionics Functionality 


Integration Complete, Fit 
issues being addressed 
in mechanical design 


Integration Complete, 
New materials 
performed adequately 


Complete, test report in 
progess. 


Testing planned for week 
of 01/23 


Testing planned for week 
of 01/23 


Testing planned for week 
of 01/23 


Testing planned for week 
of 01/23 


Acoustic 


Margin for Docking 
Performance 


Retractable Magnets 


Software Update 
Functionality 


Human Factors 


Glass Shattering 


Thermal Operating 
Limits 


Testing planned for week 
of 01/30 


Testing planned for week 
of 01/30 


Testing planned for week 
of 01/30 


Testing planned for week 
of 01/30 


Testing planned for week 
of 01/30 


Testing planned for week 
of 02/06 


Testing planned for week 
of 02/06 


Testing planned for week 
of 02/13 


Visual 
Environment 


Lighting 


Ground 
Truth Data 


Wireless 
Network 


Dock Power 


Positioning 


Vv Partial 
Module 


V Incorrect 
geometry, 
correct 
illumination 


Vv Visualeyez 
JSL WAP 


120V 


power supply | 


Goniometer 
In progress 


¢ Impacts 
¢ Testing limited in orientations 
¢ Power Supply nearly complete and not used until 
Cert 


¢ Small WAP in use 


Visual 
Environment 


Lighting 


Ground 
Truth Data 


Wireless 
Network 


Dock Power 


Positioning 


MGTFE Facility Develooment 


Vv Full 
Module 


% Correct 
geometry, 
correct 
illumination 


* Visualeyez 
3 JSL WAP 


VY NA 


% Gimbal 
and Gantry 


¢ Impacts 
¢ Temporary illumination similar to Granite Lab 
¢ Small WAP in use 
¢ Positioning limited to 5-DOF 
e Remaining visualeyez LEDs on order 


Cert Schedule 


January February March April May June July August September 


co P4D Complete 


Procedures Procurement 
—_ . 
0.4: Assembly 
’ QA Review > } 
—— 
¥ 
Integration < » "ar 
Review es 
© Test Review 
General 
‘ Granite Lab 
MGTF 
» 
Ames 
| JSC 
» WSTF 
After 
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Astrobee Delta PTR3 


Safety 


Safety Status 


4 ¢ PSRP Delta Phase 2 held January 11 & 12, 2017; 


covered the alc 


Disposition 


Comments 


Safety Data Package 28626 | Approved with Mods Minor additional details requested, update to 
Delta PTR-3 maturity 


Standard Hazards: 


Material Flammability 


Materials Off-gassing 


Mechanical/Sharp Edges 


Touch Temperature 
Shatterable Materials (lenses) 
Electromagnetic Radiation 
Lasers 

Electrical Power 

Electrical Mate/Demate 
Rotating Equipment 
Translation Paths Interference 


Vented Containers Failure 


Approved with Mods 


Mostly clarifications, move vibration to Glass HR, 
remove External Charger (covered by GeoCam 
Project) 


Safety Status (Cont) 


Topic Disposition Comments 


Collision 8628 | Approved with Mods Hazard Control plus Equivalent Safety Non- 
Compliance Report 


Li-lon Battery Approved with Mods Update EP-03 form and attach to hazard 


Cause, remove External Charger 


2 
30720 | Approved with Mods Remove External Charger 


Battery Charger 


Mate/Demate & Electrical Shock a Approved with Mods Split out UOP Mate/Demate into a separate 


implications for dock internal electronics 


Astrobee Glass Lenses a Approved with Mods Move vibration testing to this hazard 


Connectivity To ISS UOP Power 32417 | Approved with Mods Expand beyond the power cable to include 


History 


eA PSRP Delta Phase 2 review was requested at the 
first Phase 2 review June 7 & 8, 2016 primarily 
due to: 


¢ Clarification associated with Collision analysis and need for 
a Equivalent Safety NCR for crew impacting the free flyer 


¢ Electrical Mate/Demate hazards needed to be collected 
into a single hazard and expanded 


¢ Clarifications for hazards including details of the internal 
free flyer charger, and for connecting to ISS UOP power 
¢Many splinter meetings and technical exchanges 
leading up to the Delta Phase 2 review 


Delta Phase 2 Primary Results 


¢All hazards were approved with mods 


¢ Mostly clarifications, some additional coverage, 
format updates 


¢MVlost discussion centered around: 


¢ Collision hazard (more later) 
¢ Reviewed our analysis and testing plans 
¢ Equivalent Safety NCR — the PSRP Chairman intends to 
recommend approval to the ISS Program 
¢ Electrical hazards 


¢ Li-lon battery hazard accepted with most of the testing/analysis 
already completed (from Geocam project 


¢ Some reformatting requested for Mate/Demate and Electrical 
Shock. Expanding coverage in some areas 


¢ Decided to withdraw the External Charger hazard because it is 
already covered by the Geocam project 
¢ Firmware use related to safety critical hardware 
¢ No specific impacts to hazards identified so far 


Other Results 


¢ Electrical: 

Agreement on smart battery self protections 

¢e Agreement on use of <3A and very limited short 
circuit duration rather than an upstream power 
inhibit for battery insertion/removal from free 
flyer 

¢e Agreement on depth of battery enclosure on free 
flyer for molten metal protection (2.25”) 

¢ More details on wiring diagrams requested 

¢ Free flyer battery “hot swaps” will require an Ops 
Control to disable propulsion and Payload 


Other Results (cont) 


¢Flight Software - still non-Safety Critical 


¢ Any free flyer software updates by future Payload 
users must be monitored by SPHERES/Astrobee 
Program Office 


¢ Any changes to free flyer software would have to 
be reviewed/approved by PSRP 
¢Discussion of addressing Maintenance 
hazards for Phase 3 


¢Discussion of “Verify Once” versus “Verify 
Each Flight” for verification closures 


Collisions: Worst-Case Runaway 


¢ This is the challenging case from a safety perspective 


¢ Worst case is accelerating all the way down the longest 
corridor on ISS at max thrust 
¢ ~60-ft Columbus module to JEM windows 
¢ Note that PSRP Chairman might be willing to consider this 
full length unrealistic if we need relie 
¢ Max velocity ~2.1 m/s, ~5 mph (jogging speed) 
° Collision types/severity 
¢ Crew (primarily crew impacting free flyer) — Critical (NCR) 
¢ Windows - Marginal because of scratch panes 
¢ Structure - Marginal by staying within 125 lbf 
¢ Projecting hardware (e.g. laptop on Bogen arm) - Marginal 


¢ Accept risk that Astrobee may be inoperable after 
collision 


Columbus 
Starboard 


JEM Port End Windows 


20” diameter bulkhead windows 
port end cone 


8” diameter airlock hatch window 
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From Bulkhead Of Columbus Module 
Node 2 


ae JEM Bulkhead Window (Typical) 


ASTROBEY 


Approach Thin polycarbonate laminate 


0.44” thick 
Schott BK7 optical glass 
(not tempered) 
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Collision Analogy/Mitigation 


¢ “Bowling ball with knee pads” 
e Astrobee mass (8 kg) comparable to bowling ball (7.25 kg) 
¢ Bumpers similar material to knee pads 


¢ Analogous drop height in Earth gravity 
¢ Nominal ops: 50 cm/s = 1.3 cm or 0.5 inch drop 
¢ Worst-case: 2.1 m/s = 23 cm or 9 inch drop 
¢ Mitigation: 
¢ Thrust limiting 
¢ Stakeholders require 10 cm/s? acceleration 


¢ Design propulsion hardware to ensure thrust can’t go more than 20% above that 
° Limits maximum impact energy 


¢ Foam bumpers 
¢ Foam bumpers on propulsion modules; impact-damping material similar to athletic 
knee pads 
* Foam bounces back after impact and can be reused 
¢ Rigid hardware is recessed behind bumpers so it doesn’t contact obstacle ina .,; 
collision 


Bumper Geometry 


Bumpers at all cube corners 


*Geometry ensures any 
collision will compress 
bumpers by 0.5 inches of 
travel before contacting any 
hard parts (“bottoming 
out”) 


Bumper Design 
¢ Bumper material is ARTILAGE foam oy 
Stiff 


¢ Typically used for e.g. athletic knee pads 


¢ Bounces back after collision, reusable (unlike earlier 
baseline design using crushable foam) 


¢ Bumper shape includes inward-facing 
ribbing 
¢ Bumper stiffness tunable by changing rib width 


¢ By design, stiffness is non-isotropic under different 
load directions: 


¢ Stiffest in case 1 (load aligned with ribs) Nomex — over 


¢ Softest in case 3 (ribs buckle more easily under transverse foam 
load) 
¢ Vendor produces custom bumper shape by injection 
molding 
¢ Nomex fabric cover controls flammability 
Fabric 
hazard a 


¢ And robustly contains foam 
¢ Foam also glued to Ultem to minimize slip 


ARTiLAGE 


Bumper Collision Test Rig 


¢ Single bumper mounted on an air carriage that slides along 
a granite post, and impacts target (aluminum plate) 
* Carriage accelerated using rubber bands 


Target Bumper LVDT position sensor 


* Test single bumper, simulating collision cases 1-3 
¢ Vary bumper orientation to match case 
¢ Vary air carriage mass: 
* Case 1: Full Astrobee mass 


* Case 2: 1/2 Astrobee mass (with load distributed evenly over 
two bumpers, one bumper gets 1/2 mass) 


* Case 3: 1/4 Astrobee mass (with load distributed evenly over 
four bumpers, one bumper gets 1/4 mass) 


* Cases 2 and 3 actually have multiple possible orientations due 
to non-symmetry of bumper ribbing (see next page) 
* Approach is conservative 


* Rigid air carriage absorbs less impact energy than more 
compliant Astrobee structure 


* Target also very rigid 


* Instrumentation oe, Accelerometer 
post carriage 
* Target mounted on force table to measure force vs. time 
¢ Impact velocity measured by differentiating position, as Rubber 
measured with LVDT bands 


* Carriage also instrumented with accelerometer 
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Conclusion 


(0) ok eo (=m ald ol) EYe-lae| Reasoning behind classification 
classification 


Crew Critical Crew can translate at high speed and run into stationary 
or moving Astrobee, possibly suffering minor injuries. 
Will pursue equivalent-safety NCR. 


Window Marginal but No window damage in collisions below 75 cm/s; force 
request remains below crew pushoff load. At faster speeds, 
continuing scratch pane may fracture, but: 

PSRP ¢ Polycarbonate film excludes glass from crew cabin 


involvement -¢ Neither pressure pane is at risk 


ISS Structure Marginal Pending approval by ISS structures experts, based on 
force data from bumper collision test rig. Basic intuition 
is robot is too light, slow, and soft to damage structure. 


Projecting Hardware Marginal Projecting hardware should already be robust to crew 
pushoff loads, is typically mounted on compliant 
structure such as a Bogen arm (reducing peak force), and 
is typically ORU / non-critical-path 
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BACKUP SLIDES 


JEM Airlock Hatch Window 
Structure 


Inboard polycarbonate protective cover. 
Designed for 187.5 Ibf load 
Approach PG3-0139 Control 1 
path 


0.4” thick 
CHEMCOR (Lithium silicate) 
Chemically tempered glass 
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We can focus impact analysis on the bulkhead windows, because hatch windows are less 
vulnerable. They are (1) protected by a cover, (2) made of tempered glass, (3) smaller. 
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Bulkhead Window Collision Consequences 


¢ (This is based on common sense rather than 
rigorous engineering analysis.) 


e At the relevant impact energy, main concern is 
scratch pane structural failure 
¢ At speeds below 75 cm/s, Astrobee bumpers are 
designed to keep peak force below 125 Ibf, which is the 


rated/tested max force the scratch pane can withstand 
without damage 


¢ At speeds between 75 cm/s and 2.1 m/s, the scratch 
pane may fracture, but further damage, such as 
puncturing the polycarbonate film, or damaging a 
pressure pane, is viewed as extremely unlikely 


¢ If scratch pane fractures, polycarbonate film will 
prevent fragments from entering the crew cabin: 
no risk to crew 


|” 


¢ This leads to “marginal” hazard classification 
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New Hazard Definitions 


¢4.2 HAZARD LEVELS 


¢ Hazards are classified according to potential as 
follows: 


° 4.2.1 MARGINAL HAZARD 


¢ Any condition which may cause damage to an ISS element in a non- 
critical path or minor crew discomfort that does not require medical 
intervention from a second crewmember, and/or consultation with a 
Flight Surgeon. 


° 4.2.2 CRITICAL HAZARD 


e Any condition which may cause a non-disabling personnel injury or illness, 
loss of a major ISS element, loss of redundancy (i.e. with only a single 
hazard control remaining) for on-orbit life sustaining function, or loss of 
use of the SSRMS. 


° 4.2.3 CATASTROPHIC HAZARDS 


e Any condition which may cause a disabling or fatal personnel injury or one 
of the following: loss of ISS, loss of a crew-carrying vehicle, or loss of a 
major ground facility. 


¢[From DCN4 of SSP 51700] 


€,09 Different Types of Glass Fracture 
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Sharp object / thick glass Blunt object / thin glass 

“Gravel on the windshield” “Structural failure” 

Stresses localized Stresses distributed broadly across pane 
Surface scratched, chipped, or Glass deflects like a beam, then breaks 
punctured (This is our main concern — Astrobee is a 


blunt object, much softer than glass)” 


Glass Structural Failure 


¢ Glass is much stronger under compression than under tension 
(several orders of magnitude!) 


¢ Sheet glass structural failure almost always occurs due to 
microscopic cracks on the surface propagating inward when the 
glass is under tension 


f Crack propagation 


Microscopic surface flaw 


<_— 


Tension 


Tensile Strength 


¢ The effective tensile strength of sheet glass depends on 
the number and size of flaws on the surface 


¢ Different panes of glass in the same batch can have 
substantially different strength due to random flaws 
¢ Likelihood of breaking under load often modeled with Weibull 
distribution 
¢ Mechanical and chemical polishing can reduce the 
number of flaws 


¢ Effective tensile strength of the glass also depends on: 
¢ The amount of surface area placed under tension — a larger 
area is more likely to have a large flaw, thus weaker 
¢ The duration of the tension — shorter durations leave less time 
for crack propagation, thus glass is effectively stronger 


e rom Hatch-End Columbus Module 
ae_OOkKing Towards JEM Thru Node 2 


Collision Mitigation Tiers 


Tier Safety Purpose Controls 
rol dh d(er-) ig 


3 Yes 


Ensure that Astrobee will seldom 
collide with an obstacle at any 
speed. 


Ensure that Astrobee is unlikely to 
ever collide with an obstacle at 
speed greater than 75 cm/s. 


Ensure that Astrobee will never 
endanger critical path ISS 
functions or crew health. 


Crew awareness 
Automated path validation 
Manual path validation 
Obstacle avoidance 


Single fault tolerant over- 
speed propulsion cutoff 


Thrust limiting 
Foam bumpers 


Tier 1 Controls (Non-Safety Critical) 


¢ Crew awareness 


* Crew will be advised when/where Astrobee is flying 
¢ Activities will be scheduled using timelines, covered in daily briefings, announced by Capcom 

¢ Astrobee flight plans will avoid high-traffic areas with poor visibility 
* Prefer to operate in wide open spaces and “dead end” modules like Columbus/JEM when possible 
¢ Avoid areas where crew is moving around a lot, e.g. cargo transfer ops 


¢ Astrobee will use signal lights and speakers to notify crew that it is present 
¢ Details TBD; consulting with crew office, balance with minimizing crew annoyance 
¢ Automated path validation 


* Control station has list of keepout zones such as known obstacles, areas with high 
disturbance air flow, areas with sensitive equipment, etc. 


¢ Automatic validation checks that path maintains sufficient distance from keepouts 

¢ Manual path validation 
* Control station provides visualization of planned path in 3D model of ISS prior to execution 
* Operator can validate path based on their situation awareness about ISS environment 

¢ Obstacle avoidance 


¢ Astrobee can detect unknown obstacles ahead with its HazCam 
* The robot will stop and wait for operator assistance to continue 
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Tier 2 Controls (Non-Safety Critical) 


¢ Single fault tolerant over-speed cutoff 


¢ Two independent over-speed cutoffs 
¢ Primary pose estimator running on Low-Level Processor 
¢ Dedicated velocity estimator running in SoeedCam firmware 


¢ Each can independently shut off propulsion 


¢ Both estimate speed using robust approach 
¢ Take into account history of previous samples 
¢ Track both the speed estimate and confidence/accuracy 


¢ Tiered response: 
¢ If speed estimate confidence is too low, or there is a “mild over-speed” 
condition (~50-75 cm/s), command a stop and signal an error to the operator. 


* This response will be somewhat configurable, with caution, in case certain guest 
science experiments interfere with accurate speed sensing. 


¢ Example: Might disable this response, but add ops controls such as requiring crew 
supervision. 


¢ If speed exceeds 75 cm/s, shut off propulsion. 
¢ This response will not be configurable. 


Tier 3 Controls (Safety Critical) 


¢Thrust limiting 
¢ Stakeholders require 10 cm/s? acceleration 


¢ Design propulsion hardware to ensure thrust can’t go 
more than 20% above that 


¢ Limits maximum impact energy 


¢Foam bumpers 
¢Foam bumpers on propulsion modules; impact- 
damping material similar to athletic knee pads 
¢ Foam bounces back after impact and can be reused 
¢ Rigid hardware is recessed behind bumpers so it 
doesn’t contact obstacle in a collision 


Over-Speed Cutoff Approach 


Navcam / Mid-Level Processor \ Quen Processor) Main IMU 
Taakeysxe Sensor 
DockCam Analysis Fusion Shutoff command 
Power 
d S Controller 
PerchCam 
Stop command rower 
SpeedCam Propulsion 
Controllers 
a Microcontroller 
SpeedCam Optical Flow 
IMU Camera Disable line 
SpeedCam 
Firmware 
Ultrasonic IR TOF 
Rangefinder Rangefinder 


Over-Speed Cutoff Verification 


¢Test each of the cutoff systems 
independently (by disabling the other cutoff 
system) 


¢Use gantry testing facility, accelerate to over- 
speed condition 


°Verify propulsion module is shut off as 
intended 


Thrust Limiting Approach 


¢ Impeller motor controller firmware (COTS, proprietary) 
controls thrust of each prop module 


¢ During integration, set impeller motor controller max RPM rate 


¢ Configures what impeller RPM rate is implied by the max PWM command from our 
software 


¢ Flight software can’t accidentally reconfigure the controller on- 
orbit; that would require connecting a laptop to a debug port 

¢ Assuming motor controller behaves correctly, there is no way 
for our software to command excessive RPM rates 

¢ Off-axis thruster geometry provides redundant limit 

¢ If a single propulsion module somehow goes over the thrust 
limit, due to off-axis thrusters, the robot will fly in circles 

° To follow a straight path at higher acceleration, both 
propulsion modules would need to malfunction simultaneously 


Thrust Limiting Verification 


«Test worst-case Commands 
¢ Max PWM command to impeller motor controller 
¢ Nozzles controls set to maximize thrust 
¢Verify thrust is below limit 


at Ap 
Sa 
& 


Collision Geometry 


* Bumper design aims to keep force below 


125 Ibf limit in a 75 cm/s collision 
¢ Limit derived from scratch pane load limit: 
scratch panes were tested under simulated 
crew pushoff load —> —_> 
* Bumper stiffness optimized to minimize 
peak force at 75 cm/s 


¢« Bumpers will bottom out in higher-speed 
collisions, less effective 1. Perfect corner 2. Perfect edge impact: Load 

* But they still absorb some impact energy and impact: All load on 1 evenly distributed over 2 
spread load over a wider contact area bumper bumpers, simultaneous 


* Can focus design/testing on extreme 
collision cases 1-3 (shown at right) 


* Bumpers need to be stiff enough to avoid 
bottoming out in case 1 (highest pressure) 


« Bumpers need to be soft enough to keep total —> 
force low in case 3 (highest contact area) 


—> 


* Typical impact is less challenging than 
extreme cases, because force is distributed 
across multiple bumpers that strike at 


different times, keeping the peak total force 3. Perfect face impact: Typical impact: Load 
lower Load evenly distributed unevenly distributed over 
over 4 bumpers, 4 bumpers, non- 


simultaneous simultaneous me 


COLLISION TESTING 


Bumper Test No. 


an 


Due to non-symmetry of bumper ribbing, not all 
impact directions are equal. 


Bump 
er Test 
oe 
1M 4 


eed 


Corner C 

Core ; 

Bile E1 ’M 1 
Prop F 

ede E2 %’M 6 
cole F1 %M 3 
Face 

eTOp F2 %M a 


Face 


Collision Testing Status 


¢ Initially tested ribbed bumper 3D printed in rubber 
material (“Tango”), selected for quick prototyping 
turnaround 


¢ First Tango test results at 75 cm/s show peak force under 
or close to crew pushoff limit for all collision cases 


¢ Actual ARTILAGE material has 1.4x lower Young’s modulus than 
Tango, so forces are expected to be lower (under limit) 


¢ We just received our first molded ARTILAGE bumpers from 
the vendor 
¢ Gearing up for collision testing over the next 1-2 weeks 


¢ New tests will include runs at 2.1 m/s — ideally, the force 
measurements from this test will allow us to classify the high- 
speed structure collision risk as “marginal” 


Sample Collision Data* 


Force on target (Ibf) 


Acceleration of carriage (g) 


Position (in) 


0.15 0.20 0. 0.30 0.35 
Time (s) 


* The setup from this test is not finalized/correct for requirements 
verification, just provided as a reference example. Run 24: Tango bumper, 
collision case 3, ~75 cm/s impact velocity. 
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Astrobee Project Management 


Schedule, Budget, Top Risks 


FY 15 FY 16 FY 17 FY 18 


Activity 
O}n[o/ 3] F [Malm [4] s]0\N}O 3] F [m4 4je4 3] ¥]A)S]0\N}O| 4 F]saleds]o]Als|o|N)o} |r] Mais s]als 


Project 
Management 


Development 


Validation & 
Test 


m™ | orm 


Proto 4 & 
Proto 2 & Proto 3 & Final Design 


Requirements Prelim Design 


L1-L2] L3, IRDB L1 Controlled Milestone 


External Milestone 


Key Milestone 
| 


KO = Prototype Kickoff 
DR = Design Review 

IR= Review 
KO ODOR IR/TR TR = Test Review 


RFID Demo ial 


______TONDTFMAM SS ASTONO IF MAMI ASIOND FMAM TSASIOND TF Malus) JAS 


Budget 


men fe feo 


oe 3.15 9.95 ae | a 
($M) 


Parts Costs 


Shop Costs 
(~ 50% CS Labor, 
Free Flyer $165,400 50% Proc) 
Structure $55,000 S45K * 
CDH $12,500 
FSW - * Possibly 
Prop $81,000 $40K* reduce by 50% 
EPS $6,200 by using outside 
GNC $1,900 vendors. 
Comm $300 Still assembling 
Thermal $500 quotes. 
Arm $8,000 
Dock $50,000 
Structure $44,000 S40K * 


Avionics $6,000 


Material & fab cost only 
Assembly costs not included 


Top Risks 


Risk ID| Approach 
Trend* | Affinity 
a Flight Unit schedule 
Sc g 
M : 
pa] MO Cert Unit schedule 
Sc 
M : : 
pits] Negative mass margin 


R 
1478 Flight hardware costs & phasing 
WwW PSRP approval for operations without crew 
Sa tending 
e| oy Pose accuracy with vision based navigation 
W 
1479 QA & QC requirements 
Criticality Affinity Approach , 
T - Technical M - Mitigate to] Dock placement not determined 
C - Cost W - Watch 


Sa - Safety A - Accept 
Sc - Schedule R - Research 


DUOODT=—-rmAnxz-8r 


* Risk numbers not sequential 


Agenda 


je | nin] meme {pe 


rea as Fo 
yous | 1as__| teamteads | vesgn 


1200 | 04s Lunc 


as | 030 | | emo 


| asas | its | teamtesds | oesign 
| seso | ons | | rok 
| seas | 030 | ey | systems engineering 
| 1sas_| 030 | Jonathan | inegeatinatest 


— 45 a Safety 


1630 te 


isGoacisien 


Operations 


Technology Transition Plans 


Level 1 Requirements to be Verified on ISS 


¢ Remote control (FFREQ-75) 

e Sensor surveys (FFREQ-77) 

e Autonomous resupply (FFREQ-80) 

¢ Store science data (FFREQ-81) 

¢ Og research capabilities (FFREQ-82) 

¢ Host payloads (FFREQ-83) 

¢ Compatible with ISS crew (FFREQ-84) 

¢ Software upgrades (FFREQ-87) 

¢ Stream/record high quality video (FFREQ-89) 
¢ Multi free flyer operations (FFREQ-90) 


Success Criteria 


WV Traliaglelaamerelee tom Gainer Full Success Criteria 


ISS Demonstration of: ISS demonstration of: 
¢ Ground control ¢ Crew control 
¢ JEM/Node 2/US Lab map ¢ USOS map 
¢ Software upgrade ¢ Signal lights 
e Hazard detection ¢ Perch/unperch 
¢ Dock/undock ¢ Multi-robot operations 
e Streamed video ¢ Mobile camera operations 
¢ Payload & Guest Science (GS) 
operations 
Handover of all deliverables Completion of all transfer activities 


within FY18 


Activity Task Sequence 


* Crew Training 

¢ Ground Training 

¢ Crew Procedures 

¢ Ground Procedures 

¢ Operational Readiness Test 
¢ On-orbit Operations 


ISS Activities 


¢ Installation 


* Comm Checks (Store science data, Software upgrades, High quality 
video) 


¢ Component Checkouts 

° Initial Mapping 

¢ Basic Mobility (Remote control) 

¢ Autonomous Mobility (Autonomous resupply) 

° Crew Interface Checkout (Compatible with ISS crew) 
¢ Incremental Mapping 

¢ Astrobee “B” and “C” Commissioning 


¢ Demonstration (Sensor surveys, Og research capabilities, Host payloads) 


Handover Success Criteria 


Astrobee Verification of requirements & Successfully executed l&T 

Hardware KPPs procedures 

Astrobee Validation that sim is accurate Sim vs. Flight analysis Ops 

Simulation to flight performance report 

Flight Software ‘Verification of requirements & | Successfully executed I&T 
KPPs procedures 

Ground Verification of requirements Successfully executed I&T 

Software procedures 

Documentation Reviewed at final PTR by Signature sheet PM 
SPHERES PM 

Astrobee Final —_ Validation of flight performance Final report PM 


Report 


Commissioning Schedule 


ar Fava“ FY 18 
Activity 
Feb | Mar | Apr | May) Jun | Jul | Aug | Sept Oct | Nov | Dec | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sept 
Milestones 4} Launch Coden 
" Install & 
Activate 
Initial 
Map © 
Basic 
= Mobility © 
n| Autonomous 
ISS Activities eel) Payload 
a Demo ~» 
Astrobee 
ae Sc 
| Crew I/F 
(ae 
Ground 
Activities 
© Facilties ready for ORTs 


Risks 


e Assumes hardware on dock and launches on time 
¢ Crew time required for first several activities 
¢ Mitigation: significant schedule margin 
¢ REALM required for payload demo (minimum success 
criteria) 
¢ Mitigation: SPHERES will develop its own test 
payload 
e Success-based planning (no crew) for advanced mobility 


checkout and incremental mapping; may need crew to 
“rescue” US 


¢ Mitigation: activities will be structured to 
minimize the risk that crew will be needed 


Agenda 


je | nin] meme {pe 


Pea 30 Break 
ee a 
| sz00 | os | | ue 
pszws | oso | | temo 
|asas | tts | teamteads | vesgn 
psa3o | ons | | reo 
| saas | 030 | trey | systems engineering 
| 1sas_| 030 | sonethan | integration test 


15:45 L oon Ernie Safety 


sas_{ oss | eve _} restart _ 


a a 


Astrobee 


Delta PTR 3 Closing 


PTR schedule 


Feb 1 — Delta PTR 3 

Feb 1 — Release technical data package for review 
Feb 15 —Comments due 

Mar 1— Triage comments for impact to design and 
Cert Unit procurements 

Mar 15 — Disposition all comments, update 
documents/technical baseline 


Forward Work 


Astrobee Design 


¢ Open work described in Design Overview 
documents 


¢ Design mods from Prototype 4D testing (if any) 
SPHERES: Continue technology transition 


REALM: Continue payload integration, API 
development 


Cert/Flight Unit builds 


As TROBEX 


Mapped Products 


¢ IRG-FFOO6 
requirements 


Success Criteria 


Compliance Approach 


Requirements trace to 


. H n 1 . 
The detailed design is expected to components in the subsystem 


meet the requirements with 


adequate margins at an 
acceptable level of risk. 


Interface control documents are 
sufficiently mature to proceed 


with fabrication, assembly, 
integration, and test 


The element cost and schedule, 
are credible and within GCD/HET 2 


constraints. 


architectures. 
Review completed design. 
Technical risks identified. 


Hardware interfaces in 
requirements documents & 
CAD models 

Software ICD’s documented 
Astrobee IRB baselined 


HET Project Plan updated via 
GCD CR process. 

Cost & schedule risks 
identified in risk register. 


IRG-FFO17 Astrobee 
Design Overview 
Astrobee Risk Register 
IRG-FFOO6 System 
Requirements 

A9SP- and IRG-FFDW- 
drawings 

IRG-FFO25 GNC ICD 
IRG-FFO26 Comm ICD 


HET-2 Project Plan 
IRG-FFOO1 Astrobee 
PM Plan 

Astrobee IMS 
Astrobee Risk Register 


Success Criteria 


Compliance Approach Mapped Products 


High confidence exists in the Subsystem requirements IRG-FFO06 L3 

product baseline, and adequate trace to components in the requirements 

documentation exists to allow subsystem architectures. IRG-FFO17 Astrobee 

proceeding with fabrication, Technical risks identified. Design Overview 

assembly, integration, and test. Build-to based on Astrobee Risk Register 
procedures and drawings. IRG-FFDW and A9SP 


The product V&V requirements 


Develop VM and verification] * IRG-FFOO6 requirements 
and plans are complete. 


description for each req. IRG-FFOO7 I&T Plan 


The testing approach is 
comprehensive, and the planning 
for system assembly, integration, IRG-FFTEST-XXX 


I&T procedures drafted and 


practiced with Prototype 4. RS era el EHECKOULS: 


Test Procedures 


test, and launch site and mission 
operations is sufficient to progress 
into the next phase. 


¢ Identify technical 
performance measures that 
support Astrobee KPPs and 
mis quate tecnica! key requirements. IRG-FFO02-02 Astrobee TPMs 


margins exist. ales a : .; 
aa Margins listed for major Astrobee Risk Register 


milestones. 

Risk opened for negative 

margin. 
Risks to mission success 
are understood and Risks identified and action 
credibly assessed, and plans formulated. Astrobee Risk Register 
plans and resources exist Top risks elevated to HET-2 GCD Quarterly Reports 
to effectively manage and GCD. 
them. 


Success Criteria 


Compliance Approach Mapped Products 


SMA has been adequately ¢ Compliance with safety IRG-FFO18 Astrobee Safety 
addressed in system and requirements and PSRP Data Package 

operational designs, and is at processes. Astrobee Standard & 

the appropriate maturity level} * SMA Plan based on customer Unique Hazards 

for this phase of the life cycle.| agreement with Code QS. IRG-FFOO3 SMA Plan 


¢ Detailed conops and functional 
flows developed to resolve 
system & subsystem 
requirements and interactions 
¢ Develop Ops Con with POIC 


IRG-FFOO9 Astrobee 
ConOps 

IRG-FFB-XXX Functional 
Blocks 


The operational concept has 
matured, is at the appropriate 
level of detail, and has been 
considered in test planning. 


oF Success Criteria 


Compliance Approach Mapped Products 


Engineering prototypes have | ° Iterative design, development IRG-FFOO1 Astrobee PM 
been developed and tested and testing on multiple Plan 
per plan. prototypes. Astrobee IMS 


Compliance with ISS/JSC/MSFC| * Astrobee Payload 

processes for ISS payloads. Integration Agreement. 

Compliance with ISS launch Astrobee IRB 

and on-orbit requirements for IRGFFRP-003 PTR3 data 

ISS payloads. package, which includes 

PM and SE practices leveraged | __ all Astrobee planning 

from NPR/APR/Handbooks. documents. 

Open design identified. 

Forward work captured in 

these charts. 

¢ CR comments in consolidated 
form. 


The element has 
demonstrated an appropriate 
implementation of ISS, Ames 
and NASA requirements, 
standards, processes, and 
procedures. 


JIRA “Astrobee-TBD” filter 
IRGFFRP-003D PTR3D data 
package 

CROO7 


Open items/issues are clearly 
identified with acceptable 
plans and schedule for their 
disposition. 


Closing Remarks 


